From pf@net.alphadv.de Mon May  2 00:56:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 May 2005 00:56:17 +0100 (BST)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:49413 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8224976AbVEAX4C>; Mon, 2 May 2005 00:56:02 +0100
Received: from Snailmail (217.249.208.245)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Mon, 2 May 2005 01:53:43 +0200
Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id j41NtJMI001296
	for <linux-mips@linux-mips.org>; Mon, 2 May 2005 01:55:20 +0200
Received: from localhost (pf@localhost)
	by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id BAA03032
	for <linux-mips@linux-mips.org>; Mon, 2 May 2005 01:55:08 +0200
Date:	Mon, 2 May 2005 01:55:08 +0200 (CEST)
From:	peter fuerst <pf@net.alphadv.de>
To:	linux-mips@linux-mips.org
Subject: Bus error question...
Message-ID: <Pine.LNX.4.21.0505020149150.3024-100000@Opal.Peter>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: pf@net.alphadv.de
Return-Path: <pf@net.alphadv.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7842
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pf@net.alphadv.de
Precedence: bulk
X-list: linux-mips



Hi,

this question is posted here in the hope, it will be picked up and answered
by some of the <*@*engr.sgi.com> gurus, i apologize to the other members of
this mailing-list for annoying them with it as well ;-)

Is it save to assume, that memory bus errors (mc cpu_error_stat & 0x400) on
IP28 - due to R10k's precise exception model - can be asynchronous only when
caused by an aborted (misspeculated) instruction ?
The R10k manual, experiences with spurious bus errors and experiments with
"real" and speculated loads/stores seem to suggest this.
Moreover, could it be enough to recognize the bus error as asynchrounous,
when the exception code in cp0_cause doesn't say "Instruction bus error
exception" (6) or "Data bus..." (7), but "Interrupt" (0) ?  (i.e. without
analyzing the instruction at epc and register contents)

Rationale for this question: if a memory bus error can reliably be identified
as originating from a misspeculated memory access, it would be possible to get
rid of the myriads of cache barriers before *loads* (stores will remain
protected by cache barriers anyway) again, and spending some thousand machine
cycles on analyzing a bus error every three days of uptime is clearly more
efficient than having a cache barrier in kernel code every seventeen
instructions...

with kind regards

pf



From aaron@monkey.org Mon May  2 19:43:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 May 2005 19:43:47 +0100 (BST)
Received: from naughty.monkey.org ([IPv6:::ffff:65.23.81.140]:43415 "EHLO
	naughty.monkey.org") by linux-mips.org with ESMTP
	id <S8225346AbVEBSn1>; Mon, 2 May 2005 19:43:27 +0100
Received: by naughty.monkey.org (Postfix, from userid 6)
	id 38504536E32; Mon,  2 May 2005 14:43:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by naughty.monkey.org (Postfix) with ESMTP id 2DAA3536E25
	for <linux-mips@linux-mips.org>; Mon,  2 May 2005 14:43:24 -0400 (EDT)
Date:	Mon, 2 May 2005 14:43:24 -0400 (EDT)
From:	Aaron Campbell <aaron@monkey.org>
To:	linux-mips@linux-mips.org
Subject: BCM91250E (Sentosa) boot problem
Message-ID: <Pine.BSO.4.58.0505021414300.29936@naughty.monkey.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <aaron@monkey.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7843
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aaron@monkey.org
Precedence: bulk
X-list: linux-mips

I've checked out HEAD of the linux-mips CVS linux/ module (2.6.12-rc3) and
my resulting kernel will not boot on my BCM91250E (Sentosa) board.  Here
is what I get when I attempt to boot it from CFE:

ARTIS> boot -elf 172.16.1.1:/vmlinux-2.6.11
Loader:elf Filesys:tftp Dev:eth0 File:172.16.1.1:/vmlinux-2.6.11 Options:(null)
Loading: 0xffffffff80100000/3527588 0xffffffff8045d3a4/113804 Entry at 0xffffffff8036b000
Closing network.
Starting program at 0xffffffff8036b000
[RUN!]Broadcom SiByte BCM1250 B2 @ 700 MHz (SB1 rev 2)
Board type: SiByte BCM91250E (Sentosa)
[EXC!]**Exception 8: EPC=FFFFFFFF801D763C, Cause=00008008, VAddr=0000000000000000
                RA=FFFFFFFF801D80D8, PRID=0000000001040102

        0  ($00) = 0000000000000000     AT ($01) = 0000000010000080
        v0 ($02) = 0000000010000080     v1 ($03) = 0000000000000001
        a0 ($04) = 0000000000000000     a1 ($05) = 0000000000000000
        a2 ($06) = 0000000000000030     a3 ($07) = FFFFFFFF80460000
        t0 ($08) = 0000000010000080     t1 ($09) = FFFFFFFF81E02E98
        t2 ($10) = FFFFFFFFA0000000     t3 ($11) = FFFFFFFFB0060120
        t4 ($12) = FFFFFFFF803038A8     t5 ($13) = FFFFFFFFFFFFFFFF
        t6 ($14) = 0000000000000000     t7 ($15) = 0000000000000002
        s0 ($16) = FFFFFFFF803884B4     s1 ($17) = FFFFFFFF803884B4
        s2 ($18) = FFFFFFFF802D0000     s3 ($19) = FFFFFFFF80380000
        s4 ($20) = FFFFFFFF81E02E30     s5 ($21) = FFFFFFFF81E1B500
        s6 ($22) = 0000000000000000     s7 ($23) = 0000000000000000
        t8 ($24) = FFFFFFFFFFFFFFFF     t9 ($25) = 0000000000000000
        k0 ($26) = FFFFFF6630313032     k1 ($27) = FFFFFFFF80303DD0
        gp ($28) = FFFFFFFF80302000     sp ($29) = FFFFFFFF80303DB8
        fp ($30) = 0000000000000000     ra ($31) = FFFFFFFF801D80D8

[ARTI][S   ][DEBU][G
][VER8][L1CI][L2CI][TST1][CPU1][cpu1][DRAM][RAMX][ZBSS][DATA][MAIN][KMEM][CONS][CIOK]

I found the general area of address '801d763c' in System.map, and it
appears to fail in the xicor code -- xicor_read() I think, when probing to
see if the real-time clock device exists.  There is indeed one of these on
the board, i.e.,

ARTIS> show devices
Device Name          Description
-------------------  ---------------------------------------------------------
[... snip ...]
clock0               Xicor X1241 RTC on SMBus channel 1

For what it's worth, Linux 2.4.30 boots and works on the same board.  I
also tried 2.6.11.7 from kernel.org and it failed in the same manner as
shown above.  I tried disabling some options, like SMP, to no avail.

Any suggestions?  Is it possible I need to flash-upgrade the CFE firmware?

Here's my .config file:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc3
# Mon May  2 18:06:20 2005
#
CONFIG_MIPS=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_CPUSETS is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Machine selection
#
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_DB1550 is not set
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_NEC_OSPREY is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_SIBYTE_SWARM is not set
CONFIG_SIBYTE_SENTOSA=y
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_SIBYTE_SB1250=y
CONFIG_SIBYTE_SB1xxx_SOC=y
# CONFIG_CPU_SB1_PASS_1 is not set
# CONFIG_CPU_SB1_PASS_2_1250 is not set
CONFIG_CPU_SB1_PASS_2_2=y
# CONFIG_CPU_SB1_PASS_4 is not set
# CONFIG_CPU_SB1_PASS_2_112x is not set
# CONFIG_CPU_SB1_PASS_3 is not set
CONFIG_SIBYTE_HAS_LDT=y
# CONFIG_SIMULATION is not set
CONFIG_SIBYTE_CFE=y
CONFIG_SIBYTE_CFE_CONSOLE=y
# CONFIG_SIBYTE_BUS_WATCHER is not set
# CONFIG_SIBYTE_SB1250_PROF is not set
# CONFIG_SIBYTE_TBPROF is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_COHERENT=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_SWAP_IO_SPACE=y
CONFIG_BOOT_ELF32=y
CONFIG_MIPS_L1_CACHE_SHIFT=5

#
# CPU selection
#
# CONFIG_CPU_MIPS32 is not set
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
CONFIG_CPU_SB1=y
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_MIPS32=y
# CONFIG_MIPS64 is not set
# 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_SIBYTE_DMA_PAGEOPS is not set
CONFIG_CPU_HAS_PREFETCH=y
CONFIG_SB1_PASS_2_WORKAROUNDS=y
# CONFIG_64BIT_PHYS_ADDR is not set
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_LLDSCD=y
CONFIG_CPU_HAS_SYNC=y
# CONFIG_HIGHMEM is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
# CONFIG_PREEMPT is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_HW_HAS_PCI=y
CONFIG_PCI=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_MMU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_TRAD_SIGNALS=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="/home/aaron/ramfs/"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# 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=y
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_BLK_DEV_IDE_SWARM 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_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_RAID6 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
# CONFIG_ATM_CLIP_NO_ICMP is not set
# CONFIG_ATM_LANE is not set
# CONFIG_ATM_BR2684 is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_ATM is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_ROUTE is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# 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

#
# 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_NET_SB1250_MAC=y
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# 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=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
CONFIG_NET_WIRELESS=y

#
# Wan interfaces
#
CONFIG_WAN=y
# CONFIG_DSCC4 is not set
# CONFIG_LANMEDIA is not set
# CONFIG_SYNCLINK_SYNCPPP is not set
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set

#
# ATM drivers
#
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
CONFIG_STALDRV=y
CONFIG_SIBYTE_SB1250_DUART=y
CONFIG_SIBYTE_SB1250_DUART_CONSOLE=y

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# 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_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
CONFIG_I2C_ALGO_SIBYTE=y

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
CONFIG_I2C_SIBYTE=y
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# 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_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_SMIVGX is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_E1356 is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set

#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE=""
# CONFIG_SB1XXX_CORELIS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y

From ralf@linux-mips.org Tue May  3 12:19:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 12:19:23 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:57357 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225439AbVECLTE>; Tue, 3 May 2005 12:19:04 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j43BIwdt015132;
	Tue, 3 May 2005 12:18:58 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j43BIw4q015131;
	Tue, 3 May 2005 12:18:58 +0100
Date:	Tue, 3 May 2005 12:18:57 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	peter fuerst <pf@net.alphadv.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: Bus error question...
Message-ID: <20050503111857.GR24693@linux-mips.org>
References: <Pine.LNX.4.21.0505020149150.3024-100000@Opal.Peter>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0505020149150.3024-100000@Opal.Peter>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7844
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, May 02, 2005 at 01:55:08AM +0200, peter fuerst wrote:

> this question is posted here in the hope, it will be picked up and answered
> by some of the <*@*engr.sgi.com> gurus, i apologize to the other members of
> this mailing-list for annoying them with it as well ;-)

They've sold their souls to the evil empire.

> Is it save to assume, that memory bus errors (mc cpu_error_stat & 0x400) on
> IP28 - due to R10k's precise exception model - can be asynchronous only when
> caused by an aborted (misspeculated) instruction ?
> The R10k manual, experiences with spurious bus errors and experiments with
> "real" and speculated loads/stores seem to suggest this.
> Moreover, could it be enough to recognize the bus error as asynchrounous,
> when the exception code in cp0_cause doesn't say "Instruction bus error
> exception" (6) or "Data bus..." (7), but "Interrupt" (0) ?  (i.e. without
> analyzing the instruction at epc and register contents)
> 
> Rationale for this question: if a memory bus error can reliably be identified
> as originating from a misspeculated memory access, it would be possible to get
> rid of the myriads of cache barriers before *loads* (stores will remain
> protected by cache barriers anyway) again, and spending some thousand machine
> cycles on analyzing a bus error every three days of uptime is clearly more
> efficient than having a cache barrier in kernel code every seventeen
> instructions...

Supposedly cache barrier instructions on the R10000 are relativly cheap
but so far due to the lack of a need we haven't actually benchmarked that.

As I recall the issue loads would still fetch the line from memory
which in case of DMA buffers could result in stale data unless a cache
flush is being performed after the DMA as well.

  Ralf

From ralf@linux-mips.org Tue May  3 20:11:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 20:11:28 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:30476 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225539AbVECTLM>; Tue, 3 May 2005 20:11:12 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j43JB6Bn028121;
	Tue, 3 May 2005 20:11:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j43JB5Ls028120;
	Tue, 3 May 2005 20:11:05 +0100
Date:	Tue, 3 May 2005 20:11:05 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Aaron Campbell <aaron@monkey.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: BCM91250E (Sentosa) boot problem
Message-ID: <20050503191105.GC24693@linux-mips.org>
References: <Pine.BSO.4.58.0505021414300.29936@naughty.monkey.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.BSO.4.58.0505021414300.29936@naughty.monkey.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7845
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, May 02, 2005 at 02:43:24PM -0400, Aaron Campbell wrote:

> I've checked out HEAD of the linux-mips CVS linux/ module (2.6.12-rc3) and
> my resulting kernel will not boot on my BCM91250E (Sentosa) board.  Here
> is what I get when I attempt to boot it from CFE:

Sentosa is one of the rarely exercised platforms.  After a bit of digging
the last user report about it is from past November ...

  Ralf

From drow@nevyn.them.org Tue May  3 20:15:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 20:15:28 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:47565 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225539AbVECTPF>;
	Tue, 3 May 2005 20:15:05 +0100
Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian))
	id 1DT2rC-0000yN-PO; Tue, 03 May 2005 15:14:58 -0400
Date:	Tue, 3 May 2005 15:14:58 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Aaron Campbell <aaron@monkey.org>, linux-mips@linux-mips.org
Subject: Re: BCM91250E (Sentosa) boot problem
Message-ID: <20050503191458.GA3640@nevyn.them.org>
References: <Pine.BSO.4.58.0505021414300.29936@naughty.monkey.org> <20050503191105.GC24693@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l"
Content-Disposition: inline
In-Reply-To: <20050503191105.GC24693@linux-mips.org>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7846
X-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


--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, May 03, 2005 at 08:11:05PM +0100, Ralf Baechle wrote:
> On Mon, May 02, 2005 at 02:43:24PM -0400, Aaron Campbell wrote:
> 
> > I've checked out HEAD of the linux-mips CVS linux/ module (2.6.12-rc3) and
> > my resulting kernel will not boot on my BCM91250E (Sentosa) board.  Here
> > is what I get when I attempt to boot it from CFE:
> 
> Sentosa is one of the rarely exercised platforms.  After a bit of digging
> the last user report about it is from past November ...

I nag you about it from time to time :-)  My current kernel is from
HEAD as of 2005-04-28.  Here's the .config I'm using, it works OK in UP
(I haven't tried SMP lately).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=sentosa-config

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2
# Wed Apr 13 09:16:48 2005
#
CONFIG_MIPS=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y

#
# Machine selection
#
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_DB1550 is not set
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_NEC_OSPREY is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_SIBYTE_SWARM is not set
CONFIG_SIBYTE_SENTOSA=y
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_SIBYTE_SB1250=y
CONFIG_SIBYTE_SB1xxx_SOC=y
# CONFIG_CPU_SB1_PASS_1 is not set
CONFIG_CPU_SB1_PASS_2_1250=y
# CONFIG_CPU_SB1_PASS_2_2 is not set
# CONFIG_CPU_SB1_PASS_4 is not set
# CONFIG_CPU_SB1_PASS_2_112x is not set
# CONFIG_CPU_SB1_PASS_3 is not set
CONFIG_CPU_SB1_PASS_2=y
CONFIG_SIBYTE_HAS_LDT=y
# CONFIG_SIMULATION is not set
CONFIG_SIBYTE_CFE=y
# CONFIG_SIBYTE_CFE_CONSOLE is not set
# CONFIG_SIBYTE_BUS_WATCHER is not set
# CONFIG_SIBYTE_SB1250_PROF is not set
# CONFIG_SIBYTE_TBPROF is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_COHERENT=y
CONFIG_CPU_BIG_ENDIAN=y
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_SWAP_IO_SPACE=y
CONFIG_BOOT_ELF32=y
CONFIG_MIPS_L1_CACHE_SHIFT=5

#
# CPU selection
#
# CONFIG_CPU_MIPS32 is not set
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
CONFIG_CPU_SB1=y
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_MIPS32 is not set
CONFIG_MIPS64=y
CONFIG_64BIT=y
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_SIBYTE_DMA_PAGEOPS is not set
CONFIG_SB1_PASS_2_WORKAROUNDS=y
CONFIG_SB1_PASS_2_1_WORKAROUNDS=y
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_LLDSCD=y
CONFIG_CPU_HAS_SYNC=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_HW_HAS_PCI=y
CONFIG_PCI=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set
CONFIG_MMU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_BUILD_ELF64=y
CONFIG_MIPS32_COMPAT=y
CONFIG_COMPAT=y
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_BINFMT_ELF32=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=9220
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
CONFIG_INET_TUNNEL=m
CONFIG_IP_TCPDIAG=m
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
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 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_NET_SB1250_MAC=y
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# 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

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_LIBPS2 is not set
CONFIG_SERIO_RAW=m
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
CONFIG_SIBYTE_SB1250_DUART=y
CONFIG_SIBYTE_SB1250_DUART_CONSOLE=y

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# 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_LOCKD_V4=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE=""
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_KGDB is not set
# CONFIG_SB1XXX_CORELIS is not set
# CONFIG_RUNTIME_DEBUG is not set
# CONFIG_MIPS_UNCACHED is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=m
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_TEA=m
# CONFIG_CRYPTO_ARC4 is not set
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y

--XsQoSWH+UP9D9v3l--

From quekio@gmail.com Tue May  3 20:56:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 20:56:49 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.205]:12535 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8225545AbVECT4d> convert rfc822-to-8bit;
	Tue, 3 May 2005 20:56:33 +0100
Received: by wproxy.gmail.com with SMTP id 57so1479696wri
        for <linux-mips@linux-mips.org>; Tue, 03 May 2005 12:56: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:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=AtOphbTiY4GLwc0k0An1g+3tUFZqDVzouK1Tzlwo9xpoK7tiIbcqBuB6TkOZ0lICpkNXfkF1P1amcB3oDw2NXCOXiJooCpMiaook71hmJY96oL6yd5NbGt2v2b8vkTuyYyKgDrRnGt/VoEMmY1bPfn3/cjcUgOfF5Dl+Zcfytt4=
Received: by 10.54.122.12 with SMTP id u12mr629858wrc;
        Tue, 03 May 2005 12:56:26 -0700 (PDT)
Received: by 10.54.38.20 with HTTP; Tue, 3 May 2005 12:56:26 -0700 (PDT)
Message-ID: <e02bc66105050312564d0dacdb@mail.gmail.com>
Date:	Tue, 3 May 2005 21:56:26 +0200
From:	Sergio Ruiz <quekio@gmail.com>
Reply-To: Sergio Ruiz <quekio@gmail.com>
To:	linux-mips@linux-mips.org
Subject: How to the the physical addresses under linux (au1500)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <quekio@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7847
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quekio@gmail.com
Precedence: bulk
X-list: linux-mips

I am trying to program  the DMA (with the ac97) in assembler using a
linux kernel module for mips teaching purposes.
The problem is that I need to get the physical address of the pointer
to the buffer to transfer to the AC97.
Looking at the kernel source code, I found that I can get the physical
address subtracting 0x8000000, but It doesnt seem to work.

Any idea?

Thanks,

Sergio

From dan@embeddededge.com Tue May  3 21:10:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 21:10:15 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:20999 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225545AbVECUKA>; Tue, 3 May 2005 21:10:00 +0100
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j43K3ifg027627;
	Tue, 3 May 2005 16:03:44 -0400
In-Reply-To: <e02bc66105050312564d0dacdb@mail.gmail.com>
References: <e02bc66105050312564d0dacdb@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <f2bcc2c8588140446359a0f5f5cf78ca@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddededge.com>
Subject: Re: How to the the physical addresses under linux (au1500)
Date:	Tue, 3 May 2005 16:09:58 -0400
To:	Sergio Ruiz <quekio@gmail.com>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7848
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@embeddededge.com
Precedence: bulk
X-list: linux-mips


On May 3, 2005, at 3:56 PM, Sergio Ruiz wrote:

> I am trying to program  the DMA (with the ac97) in assembler using a
> linux kernel module for mips teaching purposes.

I think you want to choose a more simple teaching example :-)

> Looking at the kernel source code, I found that I can get the physical
> address subtracting 0x8000000, but It doesnt seem to work.

Not always.  On systems like this one that are not cache coherent,
we play games with mapped addresses to get uncached spaces
or you need to apply various macros/functions to keep the space
coherent.

> Any idea?

Use a more simple example.  Maybe just update one of the
LED displays on the board.


	-- Dan


From quekio@gmail.com Tue May  3 22:04:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 22:05:04 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.203]:38420 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8225556AbVECVEt> convert rfc822-to-8bit;
	Tue, 3 May 2005 22:04:49 +0100
Received: by wproxy.gmail.com with SMTP id 57so1495024wri
        for <linux-mips@linux-mips.org>; Tue, 03 May 2005 14:04:41 -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:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=ZNDG7UDQQJVXWM9OyMAzFZK/ajdrgFqmaEtvW+NpGPCiSfobTtisXBdC1PM+mdL7zH+5ZsMfIgUccHkcQksn+2T6NpvtfVtAhnB7ozQkSdHPVdDZdglo/MAps/2uBJdjlQDfQmBicfXfEfrxEZ8EkGpsYPcIb/NyJR5h2q8d/To=
Received: by 10.54.123.20 with SMTP id v20mr1327493wrc;
        Tue, 03 May 2005 14:04:41 -0700 (PDT)
Received: by 10.54.38.20 with HTTP; Tue, 3 May 2005 14:04:41 -0700 (PDT)
Message-ID: <e02bc6610505031404eda9738@mail.gmail.com>
Date:	Tue, 3 May 2005 23:04:41 +0200
From:	Sergio Ruiz <quekio@gmail.com>
Reply-To: Sergio Ruiz <quekio@gmail.com>
To:	linux-mips@linux-mips.org
Subject: Re: How to the the physical addresses under linux (au1500)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <quekio@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7849
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quekio@gmail.com
Precedence: bulk
X-list: linux-mips

On 5/3/05, Dan Malek <dan@embeddededge.com> wrote:
>
> On May 3, 2005, at 3:56 PM, Sergio Ruiz wrote:
>
> > I am trying to program  the DMA (with the ac97) in assembler using a
> > linux kernel module for mips teaching purposes.
>
> I think you want to choose a more simple teaching example :-)

Well, in fact we are two the students, the teacher gave us a xxs1500
and invited us to go as far as we could. It is a computer arquitecture
subject, so we wanted to use some periferic under linux and
assembler(requiered) to promote GNU stuff with other students.

The other alternative was to use YAMON, but we like linux and look
around YOUR source code ;-)

>
> > Looking at the kernel source code, I found that I can get the physical
> > address subtracting 0x8000000, but It doesnt seem to work.
>
> Not always.  On systems like this one that are not cache coherent,
> we play games with mapped addresses to get uncached spaces
> or you need to apply various macros/functions to keep the space
> coherent.
>

We got the ac97 working, so we would make it much cooler if we get the
DMA working with the ac97. If there is no way, no problem.

So, If there is a way to get it I would appreciate it a lot. We use a
char device so I have to make an external program to pass the buffer.
Using this way, is there any easy way to solve the problem??


> > Any idea?
>
> Use a more simple example.  Maybe just update one of the
> LED displays on the board.
>
>
>         -- Dan
>
>

Thanks a lot! If there is no solution, dont worry,

Thanks again,

Sergio

If anyone is interested, we are documenting what we are doing, but it
is in spanish :(

From wd@denx.de Tue May  3 22:50:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 May 2005 22:50:32 +0100 (BST)
Received: from mailout11.sul.t-online.com ([IPv6:::ffff:194.25.134.85]:31878
	"EHLO mailout11.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225609AbVECVuQ>; Tue, 3 May 2005 22:50:16 +0100
Received: from fwd35.aul.t-online.de 
	by mailout11.sul.t-online.com with smtp 
	id 1DT5HO-0001pD-02; Tue, 03 May 2005 23:50:10 +0200
Received: from denx.de (XGXamoZCQeduNOMVZIU1dUBr-jaHbwzaHeoEWF05yBM-1zkUScBg6f@[84.150.93.86]) by fwd35.sul.t-online.de
	with esmtp id 1DT5HF-0Jg6080; Tue, 3 May 2005 23:50:01 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id CC9EB42A78; Tue,  3 May 2005 23:50:00 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 6A861C108D; Tue,  3 May 2005 23:50:00 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 5E5FF13CA70; Tue,  3 May 2005 23:50:00 +0200 (MEST)
To:	Sergio Ruiz <quekio@gmail.com>
Cc:	linux-mips@linux-mips.org
From:	Wolfgang Denk <wd@denx.de>
Subject: Re: How to the the physical addresses under linux (au1500) 
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Tue, 03 May 2005 23:04:41 +0200."
             <e02bc6610505031404eda9738@mail.gmail.com> 
Date:	Tue, 03 May 2005 23:49:55 +0200
Message-Id: <20050503215000.6A861C108D@atlas.denx.de>
X-ID:	XGXamoZCQeduNOMVZIU1dUBr-jaHbwzaHeoEWF05yBM-1zkUScBg6f@t-dialin.net
X-TOI-MSGID: 481a6eb4-f06e-4d41-8079-a8032b8e8e9b
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7850
X-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 <e02bc6610505031404eda9738@mail.gmail.com> you wrote:
> 
> Well, in fact we are two the students, the teacher gave us a xxs1500
> and invited us to go as far as we could. It is a computer arquitecture
> subject, so we wanted to use some periferic under linux and
> assembler(requiered) to promote GNU stuff with other students.
> 
> The other alternative was to use YAMON, but we like linux and look
> around YOUR source code ;-)

If you want to do something else:  port  U-Boot  to  this  board  and
replace YAMON. I would _really_ appreciate that :-)

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
A committee is a group that keeps the minutes and loses hours.
                                                      -- Milton Berle

From linux-mips@packetvision.com Wed May  4 15:07:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 May 2005 15:08:15 +0100 (BST)
Received: from mra02.ex.eclipse.net.uk ([IPv6:::ffff:212.104.129.89]:45457
	"EHLO mra02.ex.eclipse.net.uk") by linux-mips.org with ESMTP
	id <S8225794AbVEDOH7>; Wed, 4 May 2005 15:07:59 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mra02.ex.eclipse.net.uk (Postfix) with ESMTP id EA7AC4064E2;
	Wed,  4 May 2005 15:07:56 +0100 (BST)
Received: from mra02.ex.eclipse.net.uk ([127.0.0.1])
 by localhost (mra02.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 28074-01-55; Wed,  4 May 2005 15:07:55 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra02.ex.eclipse.net.uk (Postfix) with ESMTP id E5859406526;
	Wed,  4 May 2005 15:05:29 +0100 (BST)
Subject: Re: your mail (yosemite + 2.6.x issues)
From:	Alex Gonzalez <linux-mips@packetvision.com>
To:	Manish Lachwani <mlachwani@mvista.com>
Cc:	Bryan Althouse <bryan.althouse@3phoenix.com>,
	'Ralf Baechle' <ralf@linux-mips.org>, linux-mips@linux-mips.org
In-Reply-To: <42725C07.6050100@mvista.com>
References: <20050429135220Z8225807-1340+6357@linux-mips.org>
	 <42725C07.6050100@mvista.com>
Content-Type: text/plain
Message-Id: <1115215540.13387.18.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Wed, 04 May 2005 15:05:40 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <linux-mips@packetvision.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7851
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux-mips@packetvision.com
Precedence: bulk
X-list: linux-mips

I remember having some problem with the serial driver for the rm9000.
pmc-sierra had to supply a fix. 

Their 2.6.10-rc3-20041208 kernel had the fix applied. Sorry not to
remember more details.

Alex

On Fri, 2005-04-29 at 17:08, Manish Lachwani wrote:
> Do you load the kernel first and then do a "go"? If you load the kernel 
> first using the "load" command, then you should come back to the PMON 
> prompt where you can type a "go". I was not clear about it from your 
> email below.
> 
> Thanks
> Manish Lachwani
> 
> Bryan Althouse wrote:
> 
> >Thanks Ralf, now I can compile the kernel.  But, I don't get any serial
> >console output when I try to boot it.  Actually, I get a single line that
> >looks like this:
> >
> >Loading file: tftp://192.168.2.39/vmlinux (elf)
> >0x80100000/2288188 + 0x8032ea3c/111372(z) + 4125 syms|
> >
> >I have found PMC's "yosemite_defconfig" file and I am using it as the
> >".config". I have tried using CONFIG_PMC_INTERNAL_UART=y and I have also
> >tried commenting it out.  Either way, I get no console output.
> >
> >Thanks for the help!
> >Bryan
> >
> >-----Original Message-----
> >From: Ralf Baechle [mailto:ralf@linux-mips.org] 
> >Sent: Friday, April 29, 2005 7:03 AM
> >To: Bryan Althouse
> >Cc: linux-mips@linux-mips.org; TheNop@gmx.net
> >Subject: Re: your mail
> >
> >On Thu, Apr 28, 2005 at 03:15:49PM -0400, Bryan Althouse wrote:
> >
> >  
> >
> >>I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
> >>Somehow, I am unable to compile the kernel.  I have tried the 2.6.10
> >>    
> >>
> >kernel
> >  
> >
> >>trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
> >>linux-mips.  I am using the 3.3.x cross compile tools from
> >>ftp.pmc-sierra.com .  The 2.4.x kernels from PMC compile fine.
> >>
> >>In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
> >>       Make[3]: *** [drivers/char/agp/backend.o] Error 1
> >>    
> >>
> >
> >Configuring AGP support for a MIPS kernel is obviously nonsense.  Disable
> >CONFIG_AGP.
> >
> >  
> >
> >>In the case of 2.6.12 from linux-mips, my error looks like:
> >>	drivers/net/titan_ge.c1950: error: 'titan_device_remove"  undeclared
> >>here (not in a function)
> >>    
> >>
> >
> >Whoops, a bug.  The function indeed doesn't exist even though it should,
> >will fix that.  You will hit this bug only if compiling the titan driver
> >as a module, so workaround set CONFIG_TITAN_GE=y.  Which for the typical
> >titan-based device seems to be the preferable choice anyway.
> >
> >  Ralf
> >
> >
> >
> >  
> >
> 
> 



From linux-mips@packetvision.com Wed May  4 15:11:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 May 2005 15:11:53 +0100 (BST)
Received: from mra04.ex.eclipse.net.uk ([IPv6:::ffff:212.104.129.139]:58577
	"EHLO mra04.ex.eclipse.net.uk") by linux-mips.org with ESMTP
	id <S8225797AbVEDOLj>; Wed, 4 May 2005 15:11:39 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 369D3134498;
	Wed,  4 May 2005 15:11:37 +0100 (BST)
Received: from mra04.ex.eclipse.net.uk ([127.0.0.1])
 by localhost (mra04.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 07388-01-41; Wed,  4 May 2005 15:11:35 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id AE0C4134013;
	Wed,  4 May 2005 14:55:39 +0100 (BST)
Subject: Re:
From:	Alex Gonzalez <linux-mips@packetvision.com>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	linux-mips@linux-mips.org, TheNop@gmx.net
In-Reply-To: <20050428191608Z8225923-1340+6320@linux-mips.org>
References: <20050428191608Z8225923-1340+6320@linux-mips.org>
Content-Type: text/plain
Message-Id: <1115214949.13387.13.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Wed, 04 May 2005 14:55:49 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <linux-mips@packetvision.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7852
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux-mips@packetvision.com
Precedence: bulk
X-list: linux-mips

I had no problems compiling the linux-2.6.10 kernel from pmc-sierra's
ftp.

>       Make[3]: *** [drivers/char/agp/backend.o] Error 1

Do you need AGP support? My kernel is configured without it.

Alex

On Thu, 2005-04-28 at 20:15, Bryan Althouse wrote:
> Hello,
> 
> I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
> Somehow, I am unable to compile the kernel.  I have tried the 2.6.10 kernel
> trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
> linux-mips.  I am using the 3.3.x cross compile tools from
> ftp.pmc-sierra.com .  The 2.4.x kernels from PMC compile fine.
> 
> In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
>        Make[3]: *** [drivers/char/agp/backend.o] Error 1
> 
> 	
> In the case of 2.6.12 from linux-mips, my error looks like:
> 	drivers/net/titan_ge.c1950: error: 'titan_device_remove"  undeclared
> here (not in a function)
> 
> My compile process is like so:
> make mrproper
> make xconfig
> make oldconfig
> make ARCH=mips CROSS_COMPILE=/<tool_path>/mips64-linux-gnu-    vmlinux
> 
> Could someone share their .config with me, or make some suggestions?
> 
> Thank you,
> Bryan
> 
> 



From bryan.althouse@3phoenix.com Wed May  4 15:22:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 May 2005 15:22:41 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:40877 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225804AbVEDOW0>; Wed, 4 May 2005 15:22:26 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc12) with SMTP
          id <2005050414221801400ks6u8e>; Wed, 4 May 2005 14:22:18 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Alex Gonzalez'" <linux-mips@packetvision.com>
Cc:	<linux-mips@linux-mips.org>
Subject: RE: 
Date:	Wed, 4 May 2005 10:22:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVQszGDx8CrSHDqSta8AbdCekbhHAAAQP8Q
In-Reply-To: <1115214949.13387.13.camel@euskadi.packetvision>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050504142226Z8225804-1340+6519@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7853
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips

Thanks for your help.  Yes I do need SMP.  Jason Liu of PMC did a check on
my serial number, and found that I have rev 1.1 silicon.  He says I need rev
1.2 in order to use a 2.6.x kernel.  I have shipped my hardware back to them
for an upgrade.  Hopefully, I'll be back in business in a week or two.

Bryan

-----Original Message-----
From: Alex Gonzalez [mailto:linux-mips@packetvision.com] 
Sent: Wednesday, May 04, 2005 9:56 AM
To: Bryan Althouse
Cc: linux-mips@linux-mips.org; TheNop@gmx.net
Subject: Re:

I had no problems compiling the linux-2.6.10 kernel from pmc-sierra's
ftp.

>       Make[3]: *** [drivers/char/agp/backend.o] Error 1

Do you need AGP support? My kernel is configured without it.

Alex

On Thu, 2005-04-28 at 20:15, Bryan Althouse wrote:
> Hello,
> 
> I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
> Somehow, I am unable to compile the kernel.  I have tried the 2.6.10
kernel
> trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
> linux-mips.  I am using the 3.3.x cross compile tools from
> ftp.pmc-sierra.com .  The 2.4.x kernels from PMC compile fine.
> 
> In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
>        Make[3]: *** [drivers/char/agp/backend.o] Error 1
> 
> 	
> In the case of 2.6.12 from linux-mips, my error looks like:
> 	drivers/net/titan_ge.c1950: error: 'titan_device_remove"  undeclared
> here (not in a function)
> 
> My compile process is like so:
> make mrproper
> make xconfig
> make oldconfig
> make ARCH=mips CROSS_COMPILE=/<tool_path>/mips64-linux-gnu-    vmlinux
> 
> Could someone share their .config with me, or make some suggestions?
> 
> Thank you,
> Bryan
> 
> 





From ralf@linux-mips.org Wed May  4 17:42:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 May 2005 17:42:58 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:8466 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225931AbVEDQmm>; Wed, 4 May 2005 17:42:42 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j44GgSd4017803;
	Wed, 4 May 2005 17:42:28 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j44GgRe2017802;
	Wed, 4 May 2005 17:42:27 +0100
Date:	Wed, 4 May 2005 17:42:27 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	"'Alex Gonzalez'" <linux-mips@packetvision.com>,
	linux-mips@linux-mips.org
Subject: Re:
Message-ID: <20050504164227.GE5525@linux-mips.org>
References: <1115214949.13387.13.camel@euskadi.packetvision> <20050504142226Z8225804-1340+6519@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050504142226Z8225804-1340+6519@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7854
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, May 04, 2005 at 10:22:08AM -0400, Bryan Althouse wrote:

> Thanks for your help.  Yes I do need SMP.  Jason Liu of PMC did a check on
> my serial number, and found that I have rev 1.1 silicon.  He says I need rev
> 1.2 in order to use a 2.6.x kernel.  I have shipped my hardware back to them
> for an upgrade.  Hopefully, I'll be back in business in a week or two.

That is correct.  Earlier revisions didn't implement some functionality
that is crucial to SMP.  Since only PMC and a small number outside parties
have pre-1.2 silicon I agreed with PMC to not try to support earlier
revisions.

  Ralf

From ralf@linux-mips.org Thu May  5 15:55:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 15:56:01 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:40975 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8224990AbVEEOz0>; Thu, 5 May 2005 15:55:26 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j45EtAkv008288;
	Thu, 5 May 2005 15:55:10 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j45Et9TA008287;
	Thu, 5 May 2005 15:55:09 +0100
Date:	Thu, 5 May 2005 15:55:09 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Alex Gonzalez <linux-mips@packetvision.com>
Cc:	Bryan Althouse <bryan.althouse@3phoenix.com>,
	linux-mips@linux-mips.org, TheNop@gmx.net
Subject: Re:
Message-ID: <20050505145508.GJ17119@linux-mips.org>
References: <20050428191608Z8225923-1340+6320@linux-mips.org> <1115214949.13387.13.camel@euskadi.packetvision>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1115214949.13387.13.camel@euskadi.packetvision>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7855
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, May 04, 2005 at 02:55:49PM +0100, Alex Gonzalez wrote:

> Do you need AGP support? My kernel is configured without it.

I'm not aware of any AGP bridge for MIPS systems.

  Ralf

From bryan.althouse@3phoenix.com Thu May  5 16:08:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 16:09:09 +0100 (BST)
Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:9203 "EHLO
	rwcrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8224990AbVEEPIx>; Thu, 5 May 2005 16:08:53 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc11) with SMTP
          id <200505051508450130050on3e>; Thu, 5 May 2005 15:08:45 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Ralf Baechle'" <ralf@linux-mips.org>
Cc:	<linux-mips@linux-mips.org>
Subject: RE: 
Date:	Thu, 5 May 2005 11:08:39 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVRgnWRf9gRuQGhQ7S4aOEaCBKtJAAAJxWQ
In-Reply-To: <20050505145508.GJ17119@linux-mips.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050505150853Z8224990-1340+6554@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7856
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips

Ralf,

Right, there is no AGP.  At first, I was unable to locate the
yosemite_defconfig, so I was running xconfig without a properly defaulted
.config.  I inadvertently left the AGP support enabled.  Now that I am
starting with yosemite_defcofig as a base-line, I have no problems compiling
the kernel.

Thanks,
Bryan

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org] 
Sent: Thursday, May 05, 2005 10:55 AM
To: Alex Gonzalez
Cc: Bryan Althouse; linux-mips@linux-mips.org; TheNop@gmx.net
Subject: Re:

On Wed, May 04, 2005 at 02:55:49PM +0100, Alex Gonzalez wrote:

> Do you need AGP support? My kernel is configured without it.

I'm not aware of any AGP bridge for MIPS systems.

  Ralf



From ralf@linux-mips.org Thu May  5 16:12:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 16:12:17 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:1563 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8224990AbVEEPMA>; Thu, 5 May 2005 16:12:00 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j45FBlUs009110;
	Thu, 5 May 2005 16:11:47 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j45FBlln009109;
	Thu, 5 May 2005 16:11:47 +0100
Date:	Thu, 5 May 2005 16:11:47 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	linux-mips@linux-mips.org
Subject: Re:
Message-ID: <20050505151147.GK17119@linux-mips.org>
References: <20050505145508.GJ17119@linux-mips.org> <20050505150853Z8224990-1340+6554@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050505150853Z8224990-1340+6554@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7857
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, May 05, 2005 at 11:08:39AM -0400, Bryan Althouse wrote:

> Right, there is no AGP.  At first, I was unable to locate the
> yosemite_defconfig, so I was running xconfig without a properly defaulted
> .config.  I inadvertently left the AGP support enabled.  Now that I am
> starting with yosemite_defcofig as a base-line, I have no problems compiling
> the kernel.

Oh, I was pretty sure you'd not have AGP.  However there are a few systems
which need high graphics performance and that's where AGP would make sense,
so while it's not very likely I could see some need for AGP for such
systems and did my posting in the hope somebody would raise his hand in
case there's AGP for MIPS after all ...

  Ralf

From giometti@enneenne.com Thu May  5 16:54:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 16:54:55 +0100 (BST)
Received: from adsl-72-19.38-151.net24.it ([IPv6:::ffff:151.38.19.72]:4009
	"EHLO zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8225002AbVEEPyk> convert rfc822-to-8bit; Thu, 5 May 2005 16:54:40 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DTigN-0000AR-00
	for <linux-mips@linux-mips.org>; Thu, 05 May 2005 17:54:35 +0200
Date:	Thu, 5 May 2005 17:54:35 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	linux-mips@linux-mips.org
Subject: USB hangs on AU1100
Message-ID: <20050505155435.GA28227@enneenne.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
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: <giometti@enneenne.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7858
X-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

Hello,

I'm just using USB host support on a AU1100 developing board (DB1100
configuration) and i notice that CPU locks in function
au1xxx_start_hc():

        /* wait for reset complete (read register twice; see au1500 errata) */
        while (au_readl(USB_HOST_CONFIG),
                !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD))
                udelay(1000);

while waiting for USB controller to reset. I checked it out and I
discovered that register USB_HOST_CONFIG is fixed at value 0xe! So the
controller never reset...

Linux is 2.6.12-rc3 from CVS.

Someone knows whats wrong?

Thanks in advance,

Rodolfo Giometti

-- 

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 geert@linux-m68k.org Thu May  5 16:57:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 16:58:05 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:54013 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225002AbVEEP5k>;
	Thu, 5 May 2005 16:57:40 +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 j45FvZUu011027;
	Thu, 5 May 2005 17:57:35 +0200 (MEST)
Date:	Thu, 5 May 2005 17:57:33 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Ralf Baechle <ralf@linux-mips.org>
cc:	Alex Gonzalez <linux-mips@packetvision.com>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	TheNop@gmx.net
Subject: Re:
In-Reply-To: <20050505145508.GJ17119@linux-mips.org>
Message-ID: <Pine.LNX.4.62.0505051757070.23697@numbat.sonytel.be>
References: <20050428191608Z8225923-1340+6320@linux-mips.org>
 <1115214949.13387.13.camel@euskadi.packetvision> <20050505145508.GJ17119@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7859
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Thu, 5 May 2005, Ralf Baechle wrote:
> On Wed, May 04, 2005 at 02:55:49PM +0100, Alex Gonzalez wrote:
> 
> > Do you need AGP support? My kernel is configured without it.
> 
> I'm not aware of any AGP bridge for MIPS systems.

And you cannot even select it, since it depends on ALPHA || IA64 || PPC || X86.

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 ppopov@embeddedalley.com Thu May  5 17:42:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 17:43:00 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:17335
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225005AbVEEQmp>; Thu, 5 May 2005 17:42:45 +0100
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 5 May 2005 16:42:42 -0000
Subject: Re: USB hangs on AU1100
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Rodolfo Giometti <giometti@linux.it>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <20050505155435.GA28227@enneenne.com>
References: <20050505155435.GA28227@enneenne.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 05 May 2005 09:42:41 -0700
Message-Id: <1115311361.1614.6.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7860
X-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-05-05 at 17:54 +0200, Rodolfo Giometti wrote:
> Hello,
> 
> I'm just using USB host support on a AU1100 developing board (DB1100
> configuration) and i notice that CPU locks in function
> au1xxx_start_hc():
> 
>         /* wait for reset complete (read register twice; see au1500 errata) */
>         while (au_readl(USB_HOST_CONFIG),
>                 !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD))
>                 udelay(1000);
> 
> while waiting for USB controller to reset. I checked it out and I
> discovered that register USB_HOST_CONFIG is fixed at value 0xe! So the
> controller never reset...
> 
> Linux is 2.6.12-rc3 from CVS.
> 
> Someone knows whats wrong?

It sounds like this is a custom Au1100 based board? What boot code are
you running?  I'm guessing the SOC isn't setup correctly or you have a
HW problem.

Pete


From hch@lst.de Thu May  5 18:13:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 18:14:14 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:213.95.11.210]:53921 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225008AbVEERN7>;
	Thu, 5 May 2005 18:13:59 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j45HDi6t012005
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 5 May 2005 19:13:44 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j45HDhxv012003;
	Thu, 5 May 2005 19:13:43 +0200
Date:	Thu, 5 May 2005 19:13:43 +0200
From:	Christoph Hellwig <hch@lst.de>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Alex Gonzalez <linux-mips@packetvision.com>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	linux-mips@linux-mips.org, TheNop@gmx.net
Subject: Re:
Message-ID: <20050505171343.GA11754@lst.de>
References: <20050428191608Z8225923-1340+6320@linux-mips.org> <1115214949.13387.13.camel@euskadi.packetvision> <20050505145508.GJ17119@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050505145508.GJ17119@linux-mips.org>
User-Agent: Mutt/1.3.28i
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7861
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips

On Thu, May 05, 2005 at 03:55:09PM +0100, Ralf Baechle wrote:
> On Wed, May 04, 2005 at 02:55:49PM +0100, Alex Gonzalez wrote:
> 
> > Do you need AGP support? My kernel is configured without it.
> 
> I'm not aware of any AGP bridge for MIPS systems.

The SGI Onyx 4 and Tezro systems have AGP slots, but they a really
running as PCI-X with an odd form factor and there's no AGP GART
(which isn't needed as the systems have a real iommu)


From ths@networkno.de Thu May  5 18:20:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 18:20:39 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:63623 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8225008AbVEERUY>;
	Thu, 5 May 2005 18:20:24 +0100
Received: from port-195-158-168-232.dynamic.qsc.de ([195.158.168.232] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DTk1J-0005vj-00
	for linux-mips@linux-mips.org; Thu, 05 May 2005 19:20:17 +0200
Received: from ths by hattusa.textio with local (Exim 4.50)
	id 1DTk1J-00032D-9T
	for linux-mips@linux-mips.org; Thu, 05 May 2005 19:20:17 +0200
Date:	Thu, 5 May 2005 19:20:17 +0200
To:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: USB hangs on AU1100
Message-ID: <20050505172017.GC1628@hattusa.textio>
References: <20050505155435.GA28227@enneenne.com> <1115311361.1614.6.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1115311361.1614.6.camel@localhost.localdomain>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7862
X-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

Pete Popov wrote:
> On Thu, 2005-05-05 at 17:54 +0200, Rodolfo Giometti wrote:
> > Hello,
> > 
> > I'm just using USB host support on a AU1100 developing board (DB1100
> > configuration) and i notice that CPU locks in function
> > au1xxx_start_hc():
> > 
> >         /* wait for reset complete (read register twice; see au1500 errata) */
> >         while (au_readl(USB_HOST_CONFIG),
> >                 !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD))
> >                 udelay(1000);
> > 
> > while waiting for USB controller to reset. I checked it out and I
> > discovered that register USB_HOST_CONFIG is fixed at value 0xe! So the
> > controller never reset...
> > 
> > Linux is 2.6.12-rc3 from CVS.
> > 
> > Someone knows whats wrong?
> 
> It sounds like this is a custom Au1100 based board? What boot code are
> you running?  I'm guessing the SOC isn't setup correctly or you have a
> HW problem.

I wonder if the code works reliable. At least, a comma operator isn't a
sequence point, which means the compiler is free to change the execution
order.


Thiemo

From macro@linux-mips.org Thu May  5 18:51:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 18:51:45 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:53518 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225009AbVEERva>; Thu, 5 May 2005 18:51:30 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id CD06EF59C4; Thu,  5 May 2005 19:51:23 +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 25637-09; Thu,  5 May 2005 19:51:23 +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 8AF31E1C7A; Thu,  5 May 2005 19:51:23 +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.1/8.13.1) with ESMTP id j45HpReH016425;
	Thu, 5 May 2005 19:51:27 +0200
Date:	Thu, 5 May 2005 18:51:38 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: USB hangs on AU1100
In-Reply-To: <20050505172017.GC1628@hattusa.textio>
Message-ID: <Pine.LNX.4.61L.0505051847410.21387@blysk.ds.pg.gda.pl>
References: <20050505155435.GA28227@enneenne.com> <1115311361.1614.6.camel@localhost.localdomain>
 <20050505172017.GC1628@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/871/Thu May  5 15:50:45 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7863
X-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 Thu, 5 May 2005, Thiemo Seufer wrote:

> > > I'm just using USB host support on a AU1100 developing board (DB1100
> > > configuration) and i notice that CPU locks in function
> > > au1xxx_start_hc():
> > > 
> > >         /* wait for reset complete (read register twice; see au1500 errata) */
> > >         while (au_readl(USB_HOST_CONFIG),
> > >                 !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD))
> > >                 udelay(1000);
> > > 
> > > while waiting for USB controller to reset. I checked it out and I
> > > discovered that register USB_HOST_CONFIG is fixed at value 0xe! So the
> > > controller never reset...
> > > 
> > > Linux is 2.6.12-rc3 from CVS.
> > > 
> > > Someone knows whats wrong?
> > 
> > It sounds like this is a custom Au1100 based board? What boot code are
> > you running?  I'm guessing the SOC isn't setup correctly or you have a
> > HW problem.
> 
> I wonder if the code works reliable. At least, a comma operator isn't a
> sequence point, which means the compiler is free to change the execution
> order.

 Good point -- even though the code is valid C, it's complete rubbish.  
I'd suggest rewriting it to get something readable first.

  Maciej

From krypton@ulrich-teichert.org Thu May  5 18:56:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 18:56:37 +0100 (BST)
Received: from p549F4CCC.dip.t-dialin.net ([IPv6:::ffff:84.159.76.204]:56488
	"EHLO p549F4CCC.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225009AbVEER4W>; Thu, 5 May 2005 18:56:22 +0100
Received: from [IPv6:::ffff:62.214.77.149] ([IPv6:::ffff:62.214.77.149]:4458
	"EHLO arbas.nms.ulrich-teichert.org") by linux-mips.net with ESMTP
	id <S868816AbVEER4U>; Thu, 5 May 2005 19:56:20 +0200
Received: from arbas.nms.ulrich-teichert.org (localhost [127.0.0.1])
	by arbas.nms.ulrich-teichert.org (8.12.10/8.12.1) with ESMTP id j45Hu70g021122;
	Thu, 5 May 2005 19:56:07 +0200
Received: (from ut@localhost)
	by arbas.nms.ulrich-teichert.org (8.12.10/8.12.1/Submit) id j45Hu54Y021121;
	Thu, 5 May 2005 19:56:05 +0200
Message-Id: <200505051756.j45Hu54Y021121@arbas.nms.ulrich-teichert.org>
X-Authentication-Warning: arbas.nms.ulrich-teichert.org: ut set sender to krypton using -f
Subject: Re: USB hangs on AU1100
To:	ths@networkno.de (Thiemo Seufer)
Date:	Thu, 5 May 2005 19:56:04 +0200 (MEST)
Cc:	linux-mips@linux-mips.org ('linux-mips@linux-mips.org')
In-Reply-To: <20050505172017.GC1628@hattusa.textio> from "Thiemo Seufer" at May 05, 2005 07:20:17 PM
From:	Ulrich Teichert <krypton@ulrich-teichert.org>
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <krypton@ulrich-teichert.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7864
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krypton@ulrich-teichert.org
Precedence: bulk
X-list: linux-mips

Hi,

[del]
>I wonder if the code works reliable. At least, a comma operator isn't a
>sequence point, which means the compiler is free to change the execution
>order.

Not accordingly to the C standard, which notes strict left-to-right
execution without reordering for the comma operator.

HTH,
Uli
-- 
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24               |listening to: Suicide Drive (The Deep Eynde)
24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)

From bryan.althouse@3phoenix.com Thu May  5 18:57:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 18:57:32 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:25766 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225009AbVEER5Q>; Thu, 5 May 2005 18:57:16 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc12) with SMTP
          id <2005050517570801400g21vte>; Thu, 5 May 2005 17:57:08 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	<owner-linux-mips@oss.sgi.com>
Cc:	<linux-mips@linux-mips.org>
Subject: ATA devices attached to arbitary busses
Date:	Thu, 5 May 2005 13:56:57 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVRm9QE9/BnFJFTTLSeLMfemcyIyw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050505175716Z8225009-1340+6570@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7865
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips

owner-linux-mips@oss.sgi.com  wrote on 8/19/2002:

> We support ATA devices attached to arbitary busses. The newest ATA code
> supports arbitary mmio/pio addressing mechanisms. You don't need ISA or
> an ISA like bus.


This is good news!  We want to connect an IDE flash drive to the local bus
of an rm9224.  Of course we will have to make an IDE host adapter with an
FPGA.  Right now, I'm a bit clueless as to how to get the linux kernel to
support this.  Could someone please point me in the right direction?  What
kernel source files should I be looking at?  Is there any documentation?
Many thanks!

Bryan 



From alan@lxorguk.ukuu.org.uk Thu May  5 19:07:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 19:07:16 +0100 (BST)
Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:29589 "EHLO
	lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225009AbVEESHB>; Thu, 5 May 2005 19:07:01 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j45I5fGA023909;
	Thu, 5 May 2005 19:05:41 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j45I5e9F023908;
	Thu, 5 May 2005 19:05:40 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: ATA devices attached to arbitary busses
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	owner-linux-mips@oss.sgi.com, linux-mips@linux-mips.org
In-Reply-To: <20050505175716Z8225009-1340+6570@linux-mips.org>
References: <20050505175716Z8225009-1340+6570@linux-mips.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1115316338.19844.100.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Thu, 05 May 2005 19:05:39 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7866
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

> FPGA.  Right now, I'm a bit clueless as to how to get the linux kernel to
> support this.  Could someone please point me in the right direction?  What
> kernel source files should I be looking at?  Is there any documentation?
> Many thanks!

It really depends on the complexity of your controller. If you are just
doing PIO with generic IDE interfacing then its simply a matter of
telling Linux that there is an interface at these addresses with these
port operations and it'll just do the rest for you, except hotplug.

Basically for the standard port layouts.

	hw_regs_t hw;
	ide_hwif_t *hwif;

	memset(&hw, 0, sizeof(hw));
	ide_std_init_ports(&hw, base_port_num, ctrl_port);
	hw.irq = IRQ_LINE;
	hw.dma = NO_DMA;

	index = ide_register_hw(&hw, &hwif);

If the port layout is non standard and you use mmio etc then you need to
set hw up by hand. drivers/ide/legacy/macide.c is a good example of
interfacing a non standard controller.

Alan


From ppopov@embeddedalley.com Thu May  5 19:50:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 19:50:32 +0100 (BST)
Received: from smtp005.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.82]:58276
	"HELO smtp005.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225011AbVEESuS>; Thu, 5 May 2005 19:50:18 +0100
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp005.bizmail.sc5.yahoo.com with SMTP; 5 May 2005 18:50:14 -0000
Subject: Re: USB hangs on AU1100
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Thiemo Seufer <ths@networkno.de>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.61L.0505051847410.21387@blysk.ds.pg.gda.pl>
References: <20050505155435.GA28227@enneenne.com>
	 <1115311361.1614.6.camel@localhost.localdomain>
	 <20050505172017.GC1628@hattusa.textio>
	 <Pine.LNX.4.61L.0505051847410.21387@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 05 May 2005 11:50:14 -0700
Message-Id: <1115319014.5820.1.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7867
X-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-05-05 at 18:51 +0100, Maciej W. Rozycki wrote:
> On Thu, 5 May 2005, Thiemo Seufer wrote:
> 
> > > > I'm just using USB host support on a AU1100 developing board (DB1100
> > > > configuration) and i notice that CPU locks in function
> > > > au1xxx_start_hc():
> > > > 
> > > >         /* wait for reset complete (read register twice; see au1500 errata) */
> > > >         while (au_readl(USB_HOST_CONFIG),
> > > >                 !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD))
> > > >                 udelay(1000);
> > > > 
> > > > while waiting for USB controller to reset. I checked it out and I
> > > > discovered that register USB_HOST_CONFIG is fixed at value 0xe! So the
> > > > controller never reset...
> > > > 
> > > > Linux is 2.6.12-rc3 from CVS.
> > > > 
> > > > Someone knows whats wrong?
> > > 
> > > It sounds like this is a custom Au1100 based board? What 
> oot code are
> > > you running?  I'm guessing the SOC isn't setup correctly or you have a
> > > HW problem.
> > 
> > I wonder if the code works reliable. At least, a comma operator isn't a
> > sequence point, which means the compiler is free to change the execution
> > order.
> 
>  Good point -- even though the code is valid C, it's complete rubbish.  
> I'd suggest rewriting it to get something readable first.

Interesting. I hadn't looked at this chunk of code before.

Pete


From ths@networkno.de Thu May  5 20:19:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 20:19:20 +0100 (BST)
Received: from mx01.qsc.de ([IPv6:::ffff:213.148.129.14]:48107 "EHLO
	mx01.qsc.de") by linux-mips.org with ESMTP id <S8225210AbVEETTF>;
	Thu, 5 May 2005 20:19:05 +0100
Received: from port-195-158-168-232.dynamic.qsc.de ([195.158.168.232] helo=hattusa.textio)
	by mx01.qsc.de with esmtp (Exim 3.35 #1)
	id 1DTls9-0002ps-00; Thu, 05 May 2005 21:18:57 +0200
Received: from ths by hattusa.textio with local (Exim 4.50)
	id 1DTls8-0003hR-QR; Thu, 05 May 2005 21:18:56 +0200
Date:	Thu, 5 May 2005 21:18:56 +0200
To:	Ulrich Teichert <krypton@ulrich-teichert.org>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: USB hangs on AU1100
Message-ID: <20050505191856.GD1628@hattusa.textio>
References: <20050505172017.GC1628@hattusa.textio> <200505051756.j45Hu54Y021121@arbas.nms.ulrich-teichert.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200505051756.j45Hu54Y021121@arbas.nms.ulrich-teichert.org>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7868
X-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

Ulrich Teichert wrote:
> Hi,
> 
> [del]
> >I wonder if the code works reliable. At least, a comma operator isn't a
> >sequence point, which means the compiler is free to change the execution
> >order.
> 
> Not accordingly to the C standard, which notes strict left-to-right
> execution without reordering for the comma operator.

You are right, apparently I remembered incorrectly.


Thiemo

From Kiran_Thota@pmc-sierra.com Thu May  5 23:38:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 23:38:29 +0100 (BST)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:51966 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225254AbVEEWiN>; Thu, 5 May 2005 23:38:13 +0100
Received: (qmail 11875 invoked by uid 101); 5 May 2005 22:38:02 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by mother.pmc-sierra.com with SMTP; 5 May 2005 22:38:02 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j45MbwD8012701
	for <linux-mips@linux-mips.org>; Thu, 5 May 2005 15:38:02 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <JGC9BS8M>; Thu, 5 May 2005 15:37:58 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F259024380C6@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Kiran Thota <Kiran_Thota@pmc-sierra.com>
To:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject:  CF custom implementation
Date:	Thu, 5 May 2005 15:37:56 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Kiran_Thota@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7869
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Kiran_Thota@pmc-sierra.com
Precedence: bulk
X-list: linux-mips



Hello!,
  I am working on a MIPS-based processor SoC which has a custom CF implementation over Local Bus.
The CF doesnt support IO mode, interrupts,  32-bit support.
It has limited register support [no interface registers to reset the CF]. I am using 2.6.10 from linux-mips.
I have already written a PCMCIA/CF socket socket for the same.
The goal is to use the CF cards as memoy devices. Advise me on the path to take:

PCMCIA/CF ->CS/DS -> IDE [I found a patch to make IDE work in polled mode]
PCMCIA/CF -> CS/DS -> MTD [drivers/mtc/maps/pcmciamtd.c]

I am currently using Lexar and Hitachi Compact Flash cards.
The CIS can be read and when the Linux boots up and I invoke cardmgr [v3.2.8], it sees the device as 
ATA/IDE Fixed Disk [Func = 4 (Fixed Disk) ]
Is there a way to force it to come up in memory only mode? Please suggest.

Thanks,
Kiran


From Kiran_Thota@pmc-sierra.com Thu May  5 23:43:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 23:43:55 +0100 (BST)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:46591 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225254AbVEEWnl>; Thu, 5 May 2005 23:43:41 +0100
Received: (qmail 13206 invoked by uid 101); 5 May 2005 22:43:34 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by mother.pmc-sierra.com with SMTP; 5 May 2005 22:43:34 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j45MhXew014790;
	Thu, 5 May 2005 15:43:33 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <JGC9BTGB>; Thu, 5 May 2005 15:43:33 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F259024380C7@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Kiran Thota <Kiran_Thota@pmc-sierra.com>
To:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	"'linux-pcmcia@lists.infradead.org'" 
	<linux-pcmcia@lists.infradead.org>
Subject: pcmcia-cs package for linux-mips 2.6.10?
Date:	Thu, 5 May 2005 15:43:31 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Kiran_Thota@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7870
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Kiran_Thota@pmc-sierra.com
Precedence: bulk
X-list: linux-mips



I have downloaded pcmcia-cs package v3.2.8 [David Hinds] from sourceforge.
The  Configure file doesnt have anything for MIPS. I tweaked Configure
and config.mk step-by-step and could get cardmgr/ to compile but wasnt
successful with clients/

Is there any patch for MIPS? linux-mips 2.6.10 to be specific? Can you point
me to its porting to MIPS?

Thanks,
Kiran

From ppopov@embeddedalley.com Thu May  5 23:47:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 May 2005 23:47:16 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:22442
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225254AbVEEWrC>; Thu, 5 May 2005 23:47:02 +0100
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 5 May 2005 22:46:58 -0000
Subject: Re: pcmcia-cs package for linux-mips 2.6.10?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Kiran Thota <Kiran_Thota@pmc-sierra.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	"'linux-pcmcia@lists.infradead.org'" 
	<linux-pcmcia@lists.infradead.org>
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259024380C7@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
References: <9DFF23E1E33391449FDC324526D1F259024380C7@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 05 May 2005 15:46:53 -0700
Message-Id: <1115333213.5820.104.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7871
X-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-05-05 at 15:43 -0700, Kiran Thota wrote:
> 
> I have downloaded pcmcia-cs package v3.2.8 [David Hinds] from sourceforge.
> The  Configure file doesnt have anything for MIPS. I tweaked Configure
> and config.mk step-by-step and could get cardmgr/ to compile but wasnt
> successful with clients/
> 
> Is there any patch for MIPS? linux-mips 2.6.10 to be specific? Can you point
> me to its porting to MIPS?

Use the in-kernel client drivers instead. All you need from the pcmcia-
cs package is the userland utilities.

Pete


From Kiran_Thota@pmc-sierra.com Fri May  6 00:32:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 00:32:30 +0100 (BST)
Received: from father.pmc-sierra.com ([IPv6:::ffff:216.241.224.13]:9606 "HELO
	father.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225257AbVEEXcP>; Fri, 6 May 2005 00:32:15 +0100
Received: (qmail 1948 invoked by uid 101); 5 May 2005 23:32:03 -0000
Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236)
  by father.pmc-sierra.com with SMTP; 5 May 2005 23:32:03 -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 j45NW3jI001058;
	Thu, 5 May 2005 16:32:03 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <JGC9B4TB>; Thu, 5 May 2005 16:32:03 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F259024380C8@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Kiran Thota <Kiran_Thota@pmc-sierra.com>
To:	"'ppopov@embeddedalley.com'" <ppopov@embeddedalley.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	"'linux-pcmcia@lists.infradead.org'" 
	<linux-pcmcia@lists.infradead.org>
Subject: RE: pcmcia-cs package for linux-mips 2.6.10?
Date:	Thu, 5 May 2005 16:32:02 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Return-Path: <Kiran_Thota@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7872
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Kiran_Thota@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

I m trying to build memory_cs.o as a module.
It aint available in kernel. What do i do?

-----Original Message-----
From: Pete Popov [mailto:ppopov@embeddedalley.com]
Sent: Thursday, May 05, 2005 3:47 PM
To: Kiran Thota
Cc: 'linux-mips@linux-mips.org'; 'linux-pcmcia@lists.infradead.org'
Subject: Re: pcmcia-cs package for linux-mips 2.6.10?


On Thu, 2005-05-05 at 15:43 -0700, Kiran Thota wrote:
> 
> I have downloaded pcmcia-cs package v3.2.8 [David Hinds] from sourceforge.
> The  Configure file doesnt have anything for MIPS. I tweaked Configure
> and config.mk step-by-step and could get cardmgr/ to compile but wasnt
> successful with clients/
> 
> Is there any patch for MIPS? linux-mips 2.6.10 to be specific? Can you point
> me to its porting to MIPS?

Use the in-kernel client drivers instead. All you need from the pcmcia-
cs package is the userland utilities.

Pete

From brodo@linta.de Fri May  6 06:38:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 06:38:48 +0100 (BST)
Received: from isilmar.linta.de ([IPv6:::ffff:213.239.214.66]:1697 "EHLO
	linta.de") by linux-mips.org with ESMTP id <S8224831AbVEFFid>;
	Fri, 6 May 2005 06:38:33 +0100
Received: (qmail 25401 invoked by uid 1000); 6 May 2005 05:38:24 -0000
Date:	Fri, 6 May 2005 07:38:24 +0200
From:	Dominik Brodowski <linux@dominikbrodowski.net>
To:	Kiran Thota <Kiran_Thota@pmc-sierra.com>
Cc:	"'ppopov@embeddedalley.com'" <ppopov@embeddedalley.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	"'linux-pcmcia@lists.infradead.org'" 
	<linux-pcmcia@lists.infradead.org>
Subject: Re: pcmcia-cs package for linux-mips 2.6.10?
Message-ID: <20050506053824.GA25388@isilmar.linta.de>
Mail-Followup-To: Kiran Thota <Kiran_Thota@pmc-sierra.com>,
	"'ppopov@embeddedalley.com'" <ppopov@embeddedalley.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	"'linux-pcmcia@lists.infradead.org'" <linux-pcmcia@lists.infradead.org>
References: <9DFF23E1E33391449FDC324526D1F259024380C8@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259024380C8@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
User-Agent: Mutt/1.5.9i
Return-Path: <brodo@linta.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7873
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux@dominikbrodowski.net
Precedence: bulk
X-list: linux-mips

On Thu, May 05, 2005 at 04:32:02PM -0700, Kiran Thota wrote:
> I m trying to build memory_cs.o as a module.
> It aint available in kernel. What do i do?

It is replaced by pcmciamtd.

	Dominik

From eckhardt@satorlaser.com Fri May  6 08:12:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 08:12:46 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.187]:9962 "EHLO
	moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225262AbVEFHMb>; Fri, 6 May 2005 08:12:31 +0100
Received: from [213.39.254.68] (helo=tuxator.satorlaser-intern.com)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0MKxQS-1DTx0f0aim-00038l; Fri, 06 May 2005 09:12:29 +0200
From:	Ulrich Eckhardt <eckhardt@satorlaser.com>
Organization: Sator Laser GmbH
To:	linux-mips@linux-mips.org
Subject: Re: CF custom implementation
Date:	Fri, 6 May 2005 09:13:50 +0200
User-Agent: KMail/1.7.2
References: <9DFF23E1E33391449FDC324526D1F259024380C6@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259024380C6@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505060913.50629.eckhardt@satorlaser.com>
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:e35cee35a663f5c944b9750a965814ae
Return-Path: <eckhardt@satorlaser.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7874
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eckhardt@satorlaser.com
Precedence: bulk
X-list: linux-mips

Kiran Thota wrote:
> I am working on a MIPS-based processor SoC which has a custom CF
> implementation over Local Bus. The CF doesnt support IO mode, interrupts, 
> 32-bit support.
> It has limited register support [no interface registers to reset the CF]. I
> am using 2.6.10 from linux-mips. I have already written a PCMCIA/CF socket
> socket for the same.
> The goal is to use the CF cards as memoy devices. Advise me on the path to
> take:
>
> PCMCIA/CF ->CS/DS -> IDE [I found a patch to make IDE work in polled mode]

Could you tell me where you found that patch?

> I am currently using Lexar and Hitachi Compact Flash cards.

CF is a standard, so this shouldn't matter.

> The CIS can be read and when the Linux boots up and I invoke cardmgr
> [v3.2.8], it sees the device as ATA/IDE Fixed Disk [Func = 4 (Fixed Disk) ]
> Is there a way to force it to come up in memory only mode? Please suggest.

I'm using a CF card attached to the PCMCIA interface of an Alchemy Au1100. 
Since my board only has a CF slot, I'm not using the whole PCMCIA stack at 
all - CONFIG_PCMCIA=no and no cardmgr. All I do is detect the card, parse the 
CIS and register the CF card with the IDE/ATA system of the kernel, just like 
Alan Cox suggested in the recent thread "ATA devices attached to arbitary 
busses". One good reason for me doing so is that I need to mount the root 
filesystem from the CF but the PCMCIA stack requires user-space helpers.

Uli

From giometti@enneenne.com Fri May  6 10:18:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 10:19:10 +0100 (BST)
Received: from adsl-72-19.38-151.net24.it ([IPv6:::ffff:151.38.19.72]:29159
	"EHLO zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8225344AbVEFJSx>; Fri, 6 May 2005 10:18:53 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DTyyr-0005Q0-00; Fri, 06 May 2005 11:18:45 +0200
Date:	Fri, 6 May 2005 11:18:45 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: USB hangs on AU1100
Message-ID: <20050506091845.GB1987@enneenne.com>
References: <20050505155435.GA28227@enneenne.com> <1115311361.1614.6.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="SkvwRMAIpAhPCcCJ"
Content-Disposition: inline
In-Reply-To: <1115311361.1614.6.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.6+20040722i
Return-Path: <giometti@enneenne.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7875
X-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


--SkvwRMAIpAhPCcCJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, May 05, 2005 at 09:42:41AM -0700, Pete Popov wrote:
> It sounds like this is a custom Au1100 based board? What boot code are

Yes, but is very close to the DB1100.

> you running?  I'm guessing the SOC isn't setup correctly or you have a
> HW problem.

I selected the code for the DB1100... I'm very puzzled about this
problem!

However let me suggest you this little patch in order to advice the
user about this problem and to avoid system locks.

Ciao,

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

--SkvwRMAIpAhPCcCJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch

Index: ohci-au1xxx.c
===================================================================
RCS file: /home/cvs/linux/drivers/usb/host/ohci-au1xxx.c,v
retrieving revision 1.5
diff -u -r1.5 ohci-au1xxx.c
--- ohci-au1xxx.c	3 Apr 2005 20:39:19 -0000	1.5
+++ ohci-au1xxx.c	6 May 2005 09:14:35 -0000
@@ -38,8 +38,10 @@
 
 /*-------------------------------------------------------------------------*/
 
-static void au1xxx_start_hc(struct platform_device *dev)
+static int au1xxx_start_hc(struct platform_device *dev)
 {
+	int count = 3000;
+
 	printk(KERN_DEBUG __FILE__
 		": starting Au1xxx OHCI USB Controller\n");
 
@@ -51,11 +53,19 @@
 
 	/* wait for reset complete (read register twice; see au1500 errata) */
 	while (au_readl(USB_HOST_CONFIG),
-		!(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD)) 
+		!(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD)) {
 		udelay(1000);
+		if (--count == 0) {
+			printk(KERN_ERR __FILE__
+			": unable to reset USB host\n");
+			return -EBUSY;
+		}
+	}
 
 	printk(KERN_DEBUG __FILE__
 	": Clock to USB host has been enabled \n");
+
+	return 0;
 }
 
 static void au1xxx_stop_hc(struct platform_device *dev)
@@ -113,7 +123,11 @@
 		goto err2;
 	}
 
-	au1xxx_start_hc(dev);
+	retval = au1xxx_start_hc(dev);
+	if (retval < 0) {
+		pr_debug("au1xxx start failed");
+		goto err3;
+	}
 	ohci_hcd_init(hcd_to_ohci(hcd));
 
 	retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT);
@@ -121,6 +135,7 @@
 		return retval;
 
 	au1xxx_stop_hc(dev);
+ err3:
 	iounmap(hcd->regs);
  err2:
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);

--SkvwRMAIpAhPCcCJ--

From giometti@enneenne.com Fri May  6 11:12:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 11:12:22 +0100 (BST)
Received: from adsl-72-19.38-151.net24.it ([IPv6:::ffff:151.38.19.72]:7814
	"EHLO zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8225351AbVEFKMH>; Fri, 6 May 2005 11:12:07 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DTzoS-0006er-00
	for <linux-mips@linux-mips.org>; Fri, 06 May 2005 12:12:04 +0200
Date:	Fri, 6 May 2005 12:12:04 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	linux-mips@linux-mips.org
Subject: PCMCIA support doesn't compile
Message-ID: <20050506101204.GA25371@enneenne.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1"
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: <giometti@enneenne.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7876
X-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


--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Here a little patch in order to allow PCMCIA support to correcly
compile (file bulkmem.c has been removed).

Ciao,

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

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch

Index: Makefile
===================================================================
RCS file: /home/cvs/linux/drivers/pcmcia/Makefile,v
retrieving revision 1.39
diff -u -r1.39 Makefile
--- Makefile	25 Jan 2005 04:28:38 -0000	1.39
+++ Makefile	6 May 2005 10:05:11 -0000
@@ -32,7 +32,7 @@
 obj-$(CONFIG_PCMCIA_VRC4173)			+= vrc4173_cardu.o
 obj-$(CONFIG_PCMCIA_AU1X00)			+= au1x00_ss.o
 
-pcmcia_core-y					+= cistpl.o rsrc_mgr.o bulkmem.o cs.o socket_sysfs.o
+pcmcia_core-y					+= cistpl.o rsrc_mgr.o cs.o socket_sysfs.o
 pcmcia_core-$(CONFIG_CARDBUS)			+= cardbus.o
 
 sa11xx_core-y					+= soc_common.o sa11xx_base.o

--n8g4imXOkfNTN/H1--

From giometti@enneenne.com Fri May  6 11:19:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 11:19:41 +0100 (BST)
Received: from adsl-72-19.38-151.net24.it ([IPv6:::ffff:151.38.19.72]:3208
	"EHLO zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8225351AbVEFKT1>; Fri, 6 May 2005 11:19:27 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DTzvY-0006oQ-00
	for <linux-mips@linux-mips.org>; Fri, 06 May 2005 12:19:24 +0200
Date:	Fri, 6 May 2005 12:19:24 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	linux-mips@linux-mips.org
Subject: Useful (missing) patches for DB1100
Message-ID: <20050506101924.GC25371@enneenne.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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: <giometti@enneenne.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7877
X-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

As described in this message
«http://www.spinics.net/lists/mips/msg18375.html» I suggest to you to
apply the patches to files au1000_generic.c and au1000_generic.h (in
the current CVS version) in order to avoid a run time error in the
PCMCIA support and a compilation warning. :)

Ciao,

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 jerry@izmiran.rssi.ru Fri May  6 13:52:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 13:52:31 +0100 (BST)
Received: from cygnus.izmiran.rssi.ru ([IPv6:::ffff:193.232.24.21]:22440 "EHLO
	cygnus.izmiran.rssi.ru") by linux-mips.org with ESMTP
	id <S8225407AbVEFMwQ>; Fri, 6 May 2005 13:52:16 +0100
Received: from [127.0.0.1] (IDENT:10003@localhost [127.0.0.1])
	by cygnus.izmiran.rssi.ru (8.12.4/8.12.4) with ESMTP id j46Cpwcs014527
	for <linux-mips@linux-mips.org>; Fri, 6 May 2005 16:52:04 +0400
Date:	Fri, 6 May 2005 15:53:22 +0300
From:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: "Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Organization: Home
X-Priority: 3 (Normal)
Message-ID: <261758805.20050506155322@izmiran.rssi.ru>
To:	linux-mips@linux-mips.org
Subject: dbau1200 ethernet driver?
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit
Return-Path: <jerry@izmiran.rssi.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7878
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@izmiran.rssi.ru
Precedence: bulk
X-list: linux-mips


  Hi!

 I compiled last 2.6 kernel (2-3 weeks ago from cvs@linux-mips) and
trying to start it on DBAu1200 development board. First problem I
discovered with "nfsroot" configuration - is that kernel cannot find
network interface at boot-time.
 There is a smc91c111 network chip on board, so my question is - what
driver is suitable with him? Is it "MIPS AU1000 Ethernet support"
which fails to compile with "error: `NUM_ETH_INTERFACES' undeclared"
(and it must be?) or something different? It seems that I have enabled
all other options for ethernet functionality.


the part of boot log is:

loop: loaded (max 8 devices)
nbd: registered device at major 43
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: No network devices available.
Looking up port of RPC 100003/2 on 192.168.0.30
RPC: sendmsg returned error 128
portmap: RPC call returned error 128
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.0.30
RPC: sendmsg returned error 128
portmap: RPC call returned error 128
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 128
mount: RPC call returned error 128


   ()_()
--( °,° )---[21398845]-[jerry¤wicomtechnologies.com]-
  (") (")                 -<The Bat! 3.0.1.33>- -<06/05/2005 15:35>-


From sjhill@realitydiluted.com Fri May  6 14:32:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 14:32:42 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:144 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225411AbVEFNc1>; Fri, 6 May 2005 14:32:27 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.50 #1 (Debian))
	id 1DU2wJ-0006H6-Bd; Fri, 06 May 2005 08:32:23 -0500
Subject: Re: dbau1200 ethernet driver?
In-Reply-To: <261758805.20050506155322@izmiran.rssi.ru>
To:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Date:	Fri, 6 May 2005 08:32:23 -0500 (CDT)
CC:	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: <E1DU2wJ-0006H6-Bd@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7879
X-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

>  There is a smc91c111 network chip on board, so my question is - what
> driver is suitable with him? Is it "MIPS AU1000 Ethernet support"
> which fails to compile with "error: `NUM_ETH_INTERFACES' undeclared"
> (and it must be?) or something different? It seems that I have enabled
> all other options for ethernet functionality.
> 
Without having access to a source tree currently, how about you grep
through the 'arch/mips/au1000' directory and friends for the string
NUM_ETH_INTERFACES. I think you will find that each board-specific
setup file is responsible for defining it. Either that, or look in
'include/asm-mips'. In the future, make sure you grep through all of
the source to find other possible uses or examples.

-Steve

From jerry@izmiran.rssi.ru Fri May  6 15:12:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 15:12:18 +0100 (BST)
Received: from cygnus.izmiran.rssi.ru ([IPv6:::ffff:193.232.24.21]:4013 "EHLO
	cygnus.izmiran.rssi.ru") by linux-mips.org with ESMTP
	id <S8225417AbVEFOMD>; Fri, 6 May 2005 15:12:03 +0100
Received: from [127.0.0.1] (IDENT:10003@localhost [127.0.0.1])
	by cygnus.izmiran.rssi.ru (8.12.4/8.12.4) with ESMTP id j46EBjcs017862
	for <linux-mips@linux-mips.org>; Fri, 6 May 2005 18:11:52 +0400
Date:	Fri, 6 May 2005 17:12:59 +0300
From:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: "Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Organization: Home
X-Priority: 3 (Normal)
Message-ID: <135147936.20050506171259@izmiran.rssi.ru>
To:	linux-mips@linux-mips.org
Subject: Re[2]: dbau1200 ethernet driver?
In-Reply-To: <E1DU2wJ-0006H6-Bd@real.realitydiluted.com>
References: <261758805.20050506155322@izmiran.rssi.ru>
 <E1DU2wJ-0006H6-Bd@real.realitydiluted.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit
Return-Path: <jerry@izmiran.rssi.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7880
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@izmiran.rssi.ru
Precedence: bulk
X-list: linux-mips

>[In reply to "dbau1200 ethernet driver?" from sjhill@realitydiluted.com <sjhill@realitydiluted.com> to Ruslan V.Pisarev <jerry@izmiran.rssi.ru>  06/05/2005 16:32]

>>  There is a smc91c111 network chip on board, so my question is - what
>> driver is suitable with him? Is it "MIPS AU1000 Ethernet support"
>> which fails to compile with "error: `NUM_ETH_INTERFACES' undeclared"
>> (and it must be?) or something different? It seems that I have enabled
>> all other options for ethernet functionality.
src> Without having access to a source tree currently, how about you grep
src> through the 'arch/mips/au1000' directory and friends for the string
src> NUM_ETH_INTERFACES. I think you will find that each board-specific
src> setup file is responsible for defining it. Either that, or look in
src> 'include/asm-mips'. In the future, make sure you grep through all of
src> the source to find other possible uses or examples.

Well, problem is something more complicated... At least for me :)

NUM_ETH_INTERFACES is defined /include/asm-mips/mach-au1x00/au1000.h
for all machines (au1000 au1100 au1500 au1550) except au1200. I dont
think that someone forgot to add NUM_ETH_INTERFACES for au1200. And
even what it means? All these machines have "on-board" ethernet
controller in processor core, so I think there's no external chip on
development board. au1200 haven't internal controller and has
dedicated chip on board...

 Furtermore, I found now, that Linux 2.4.26 distributed by AMD has an
additional option CONFIG_AU1XXX_SMC91111 in config for DBAu1200 which
controls compiling drivers/net/smc91111.c.
 In 2.6 this file disappeared but we have drivers/net/smc91x.c which
configures in some arm, ppc, and superh architectures. MIPS knows
nothing about him. Is it the right file? I suppose it is, but...

 Am I first who put 2.6 kernel on this board and see that is there no
drivers for it ? :)




   ()_()
--( °,° )---[21398845]-[jerry¤wicomtechnologies.com]-
  (") (")                 -<The Bat! 3.0.1.33>- -<06/05/2005 16:38>-


From giometti@enneenne.com Fri May  6 15:27:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 15:27:43 +0100 (BST)
Received: from adsl-72-19.38-151.net24.it ([IPv6:::ffff:151.38.19.72]:2758
	"EHLO zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8225421AbVEFO13>; Fri, 6 May 2005 15:27:29 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DU3nT-0003gM-00; Fri, 06 May 2005 16:27:19 +0200
Date:	Fri, 6 May 2005 16:27:19 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: USB hangs on AU1100
Message-ID: <20050506142719.GA13148@enneenne.com>
References: <20050505155435.GA28227@enneenne.com> <1115311361.1614.6.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c"
Content-Disposition: inline
In-Reply-To: <1115311361.1614.6.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.6+20040722i
Return-Path: <giometti@enneenne.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7881
X-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


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

On Thu, May 05, 2005 at 09:42:41AM -0700, Pete Popov wrote:
> It sounds like this is a custom Au1100 based board? What boot code are
> you running?  I'm guessing the SOC isn't setup correctly or you have a
> HW problem.

Yes, you was right, I missing to setup USB clock... I just added this
code to the board init function (board_setup() function) and now USB
works:

    #if defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_AU1X00_USB_DEVICE)
	    /* zero and disable FREQ2 */
	    sys_freqctrl =3D au_readl(SYS_FREQCTRL0);
	    sys_freqctrl &=3D ~0xFFF00000;
	    au_writel(sys_freqctrl, SYS_FREQCTRL0);
   =20
	    /* zero and disable USBH/USBD/IrDA clock */
	    sys_clksrc =3D au_readl(SYS_CLKSRC);
	    sys_clksrc &=3D ~0x0000001F;
	    au_writel(sys_clksrc, SYS_CLKSRC);
   =20
	    sys_freqctrl =3D au_readl(SYS_FREQCTRL0);
	    sys_freqctrl &=3D ~0xFFF00000;
   =20
	    sys_clksrc =3D au_readl(SYS_CLKSRC);
	    sys_clksrc &=3D ~0x0000001F;
   =20
	    /* FREQ2 =3D aux/2 =3D 48 MHz */
	    sys_freqctrl |=3D ((0<<22) | (1<<21) | (1<<20));
	    au_writel(sys_freqctrl, SYS_FREQCTRL0);
   =20
	    /* Route 48MHz FREQ2 into USBH/USBD/IrDA */
	    sys_clksrc |=3D ((4<<2) | (0<<1) | 0 );
	    au_writel(sys_clksrc, SYS_CLKSRC);
   =20
	    /* setup the static bus controller */
	    au_writel(0x00000002, MEM_STCFG3);  /* type =3D PCMCIA */
	    au_writel(0x280E3D07, MEM_STTIME3); /* 250ns cycle time */
	    au_writel(0x10000000, MEM_STADDR3); /* any PCMCIA select */
   =20
	    /* Get USB Functionality pin state (device vs host drive pins) */
	    pin_func =3D au_readl(SYS_PINFUNC) & (u32)(~0x8000);
    #ifndef CONFIG_AU1X00_USB_DEVICE
	    /* 2nd USB port is USB host */
	    pin_func |=3D 0x8000;
    #endif
	    au_writel(pin_func, SYS_PINFUNC);
    #endif /* defined (CONFIG_USB_OHCI_HCD) || defined (CONFIG_AU1X00_USB_D=
EVICE) */

But don't you think is better to put this code into USB driver (file
ohci-au1xxx.c) during probing stage? In this manner each platforms may
don't worry about clock initialization...

Ciao,

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

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

iD8DBQFCe37HQaTCYNJaVjMRAmhHAJ9uPoekZdNWgNLi+Vjw+AmE5DyWSACeLsJk
K1jMXXbknQC2CmQZQE9jn4k=
=1YpV
-----END PGP SIGNATURE-----

--sm4nu43k4a2Rpi4c--

From macro@linux-mips.org Fri May  6 15:51:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 15:51:35 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:29710 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225459AbVEFOvT>; Fri, 6 May 2005 15:51:19 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 6E104F5CB2
	for <linux-mips@linux-mips.org>; Fri,  6 May 2005 16:51:13 +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 11801-04 for <linux-mips@linux-mips.org>;
 Fri,  6 May 2005 16:51:13 +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 2D1E2F5CAF
	for <linux-mips@linux-mips.org>; Fri,  6 May 2005 16:51:13 +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.1/8.13.1) with ESMTP id j46EpHgD014072
	for <linux-mips@linux-mips.org>; Fri, 6 May 2005 16:51:17 +0200
Date:	Fri, 6 May 2005 15:51:25 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050506143118Z8225421-1340+6642@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0505061540540.25293@blysk.ds.pg.gda.pl>
References: <20050506143118Z8225421-1340+6642@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/871/Thu May  5 15:50:45 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7882
X-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, 6 May 2005 ralf@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	05/05/06 15:31:13
> 
> Modified files:
> 	arch/mips/kernel: cpu-probe.c 
> 
> Log message:
> 	No point in checking cpu_has_tlb before we've computed the CPU options.

 ???  decode_config0() sets up the CPU option in question, so doing a 
check after decode_configs() is fine.

> 	So for now we just unconditionally set the option - Linux wouldn't
> 	work without a TLB anyway.

 I don't like the idea -- bits shouldn't be scattered all over the place, 
so that all the places need to be chased and fixed once conditions change.  

 Instead of polluting all the cpu_probe_*() functions, it should actually 
be moved to decode_config0().  I can apply a suitable fix.

  Maciej

From dan@embeddedalley.com Fri May  6 15:54:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 15:55:01 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:37394 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225459AbVEFOyr>; Fri, 6 May 2005 15:54:47 +0100
Received: from [192.168.2.27] (h69-21-252-132.69-21.unk.tds.net [69.21.252.132])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j46EmAfg004926;
	Fri, 6 May 2005 10:48:11 -0400
In-Reply-To: <20050506142719.GA13148@enneenne.com>
References: <20050505155435.GA28227@enneenne.com> <1115311361.1614.6.camel@localhost.localdomain> <20050506142719.GA13148@enneenne.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <806d447ce4c6480116ebd3d9fbaeafc6@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	Pete Popov <ppopov@embeddedalley.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: USB hangs on AU1100
Date:	Fri, 6 May 2005 10:54:36 -0400
To:	Rodolfo Giometti <giometti@linux.it>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7883
X-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 May 6, 2005, at 10:27 AM, Rodolfo Giometti wrote:

> Yes, you was right, I missing to setup USB clock...

The other thing you have to always remember when comparing
operation to "... a board just like the Db1xxx ... " is that yamon does
lots and lots of set up for the board that Linux assumes will be
done.  We've discussed this in the past, I just wanted to mention
it again so it isn't forgotten. ;-)

Thanks.


	-- Dan


From bryan.althouse@3phoenix.com Fri May  6 16:20:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 16:20:29 +0100 (BST)
Received: from rwcrmhc14.comcast.net ([IPv6:::ffff:216.148.227.89]:24481 "EHLO
	rwcrmhc14.comcast.net") by linux-mips.org with ESMTP
	id <S8225995AbVEFPUG>; Fri, 6 May 2005 16:20:06 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc14) with SMTP
          id <200505061519550140086qe8e>; Fri, 6 May 2005 15:19:55 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>
Cc:	<linux-mips@linux-mips.org>
Subject: RE: ATA devices attached to arbitary busses
Date:	Fri, 6 May 2005 11:19:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVRnTpQ2HSr6HCSTjOMsTTmmVOC6gAphcdQ
In-Reply-To: <1115316338.19844.100.camel@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050506152006Z8225995-1340+6646@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7884
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips


Alan,

Thank you, that is very helpful.  I think I understand, but let me ramble a
bit so that you can correct me if I am wrong.  

All IDE drives should have the identical memory map.  But, the kernel does
not communicate directly with the drive, it communicates though an IDE host
adaptor (which may have different implementations).  If the host adaptor's
memory map "matches" that of the IDE drive spec, then you consider it to be
a "standard port layout"?  Since my host adaptor will be implemented in an
FPGA, if I give it the IDE memory map defined in ide.h, then your example
code will be applicable.

The memory map defined in ide.h makes sense to me (it seems to match the IDE
drive memory map) until we get down to offset 6 (IDE_SELECT_OFFSET).  From
here down, I have trouble matching the #define names with the register
names/descriptions from the IDE spec.  Also, I am puzzled as to why there
are 10 registers defined in ide.h when my IDE spec only shows 9.  The IDE
spec that I am referencing looks like this:

CS0   CS1    DA2   DA1   DA0   READ              WRITE
A     N      0     0     0     Data              Data
A     N      0     0     1     Error             Features
A     N      0     1     0     Sector Count      Sector Count
A     N      0     1     1     Sector Number     Sector Number
A     N      1     0     0     Cylinder Low      Cylinder Low
A     N      1     0     1     Cylinder High     Cylinder High
A     N      1     1     0     Device/Head       Device/Head
A     N      1     1     1     Status            Command
N     A      1     1     0     Alternate Status  Device Control (IRQ en/dis)


ide.h shows the following offsets:

#define IDE_DATA_OFFSET		(0)
#define IDE_ERROR_OFFSET	(1)
#define IDE_NSECTOR_OFFSET	(2)
#define IDE_SECTOR_OFFSET	(3)
#define IDE_LCYL_OFFSET		(4)
#define IDE_HCYL_OFFSET		(5)
#define IDE_SELECT_OFFSET	(6)
#define IDE_STATUS_OFFSET	(7)
#define IDE_CONTROL_OFFSET	(8)
#define IDE_IRQ_OFFSET		(9)

Do you know of an IDE host adapter chipset which is standard?  If someone
knows of a part number, I could look up its datasheet.  This would probably
clear up my confusion.  Thanks again!  

Bryan

>It really depends on the complexity of your controller. If you are just
>doing PIO with generic IDE interfacing then its simply a matter of
>telling Linux that there is an interface at these addresses with these
>port operations and it'll just do the rest for you, except hotplug.




From ppopov@embeddedalley.com Fri May  6 16:46:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 16:46:58 +0100 (BST)
Received: from smtp002.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.126]:45978
	"HELO smtp002.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226007AbVEFPqn>; Fri, 6 May 2005 16:46:43 +0100
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp002.bizmail.yahoo.com with SMTP; 6 May 2005 15:46:39 -0000
Subject: Re: dbau1200 ethernet driver?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <261758805.20050506155322@izmiran.rssi.ru>
References: <261758805.20050506155322@izmiran.rssi.ru>
Content-Type: text/plain; charset=utf-8
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 06 May 2005 08:46:40 -0700
Message-Id: <1115394400.5785.3.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 8bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7885
X-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-05-06 at 15:53 +0300, Ruslan V.Pisarev wrote:
>   Hi!
> 
>  I compiled last 2.6 kernel (2-3 weeks ago from cvs@linux-mips) and
> trying to start it on DBAu1200 development board. First problem I
> discovered with "nfsroot" configuration - is that kernel cannot find
> network interface at boot-time.
>  There is a smc91c111 network chip on board, so my question is - what
> driver is suitable with him?

The smc91x.c driver. However, I don't remember if that driver was
tested.  The board was tested with a different smc driver which I
couldn't push in the tree because it was old and would conflict with the
smc91x.c.

>  Is it "MIPS AU1000 Ethernet support"
> which fails to compile with "error: `NUM_ETH_INTERFACES' undeclared"
> (and it must be?) or something different? It seems that I have enabled
> all other options for ethernet functionality.

Well, that's a different driver.



Pete

> 
> 
> the part of boot log is:
> 
> loop: loaded (max 8 devices)
> nbd: registered device at major 43
> NET: Registered protocol family 2
> IP: routing cache hash table of 2048 buckets, 16Kbytes
> TCP established hash table entries: 16384 (order: 5, 131072 bytes)
> TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
> TCP: Hash tables configured (established 16384 bind 16384)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> IP-Config: No network devices available.
> Looking up port of RPC 100003/2 on 192.168.0.30
> RPC: sendmsg returned error 128
> portmap: RPC call returned error 128
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 192.168.0.30
> RPC: sendmsg returned error 128
> portmap: RPC call returned error 128
> Root-NFS: Unable to get mountd port number from server, using default
> RPC: sendmsg returned error 128
> mount: RPC call returned error 128
> 
> 
>    ()_()
> --( °,° )---[21398845]-[jerry¤wicomtechnologies.com]-
>   (") (")                 -<The Bat! 3.0.1.33>- -<06/05/2005 15:35>-
> 
> 


From ppopov@embeddedalley.com Fri May  6 16:51:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 16:52:04 +0100 (BST)
Received: from smtp003.bizmail.yahoo.com ([IPv6:::ffff:216.136.130.195]:59034
	"HELO smtp003.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226008AbVEFPvr>; Fri, 6 May 2005 16:51:47 +0100
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp003.bizmail.yahoo.com with SMTP; 6 May 2005 15:51:44 -0000
Subject: Re: USB hangs on AU1100
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Rodolfo Giometti <giometti@linux.it>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <20050506142719.GA13148@enneenne.com>
References: <20050505155435.GA28227@enneenne.com>
	 <1115311361.1614.6.camel@localhost.localdomain>
	 <20050506142719.GA13148@enneenne.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 06 May 2005 08:51:45 -0700
Message-Id: <1115394705.5785.8.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7886
X-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-05-06 at 16:27 +0200, Rodolfo Giometti wrote:
> On Thu, May 05, 2005 at 09:42:41AM -0700, Pete Popov wrote:
> > It sounds like this is a custom Au1100 based board? What boot code are
> > you running?  I'm guessing the SOC isn't setup correctly or you have a
> > HW problem.
> 
> Yes, you was right, I missing to setup USB clock... I just added this
> code to the board init function (board_setup() function) and now USB
> works:
> 
>     #if defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_AU1X00_USB_DEVICE)
> 	    /* zero and disable FREQ2 */
> 	    sys_freqctrl = au_readl(SYS_FREQCTRL0);
> 	    sys_freqctrl &= ~0xFFF00000;
> 	    au_writel(sys_freqctrl, SYS_FREQCTRL0);
>     
> 	    /* zero and disable USBH/USBD/IrDA clock */
> 	    sys_clksrc = au_readl(SYS_CLKSRC);
> 	    sys_clksrc &= ~0x0000001F;
> 	    au_writel(sys_clksrc, SYS_CLKSRC);
>     
> 	    sys_freqctrl = au_readl(SYS_FREQCTRL0);
> 	    sys_freqctrl &= ~0xFFF00000;
>     
> 	    sys_clksrc = au_readl(SYS_CLKSRC);
> 	    sys_clksrc &= ~0x0000001F;
>     
> 	    /* FREQ2 = aux/2 = 48 MHz */
> 	    sys_freqctrl |= ((0<<22) | (1<<21) | (1<<20));
> 	    au_writel(sys_freqctrl, SYS_FREQCTRL0);
>     
> 	    /* Route 48MHz FREQ2 into USBH/USBD/IrDA */
> 	    sys_clksrc |= ((4<<2) | (0<<1) | 0 );
> 	    au_writel(sys_clksrc, SYS_CLKSRC);
>     
> 	    /* setup the static bus controller */
> 	    au_writel(0x00000002, MEM_STCFG3);  /* type = PCMCIA */
> 	    au_writel(0x280E3D07, MEM_STTIME3); /* 250ns cycle time */
> 	    au_writel(0x10000000, MEM_STADDR3); /* any PCMCIA select */
>     
> 	    /* Get USB Functionality pin state (device vs host drive pins) */
> 	    pin_func = au_readl(SYS_PINFUNC) & (u32)(~0x8000);
>     #ifndef CONFIG_AU1X00_USB_DEVICE
> 	    /* 2nd USB port is USB host */
> 	    pin_func |= 0x8000;
>     #endif
> 	    au_writel(pin_func, SYS_PINFUNC);
>     #endif /* defined (CONFIG_USB_OHCI_HCD) || defined (CONFIG_AU1X00_USB_DEVICE) */
> 
> But don't you think is better to put this code into USB driver (file
> ohci-au1xxx.c) during probing stage? In this manner each platforms may
> don't worry about clock initialization...

Seems too board specific since the clocks can be routed differently on
each board. 

Pete


From ppopov@embeddedalley.com Fri May  6 17:17:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 17:18:19 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:16484
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226013AbVEFQR5>; Fri, 6 May 2005 17:17:57 +0100
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 6 May 2005 16:17:49 -0000
Subject: Re: Re[2]: dbau1200 ethernet driver?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <135147936.20050506171259@izmiran.rssi.ru>
References: <261758805.20050506155322@izmiran.rssi.ru>
	 <E1DU2wJ-0006H6-Bd@real.realitydiluted.com>
	 <135147936.20050506171259@izmiran.rssi.ru>
Content-Type: multipart/mixed; boundary="=-Prjo5kPrED460n4iSWkI"
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 06 May 2005 09:17:50 -0700
Message-Id: <1115396270.5785.10.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7887
X-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


--=-Prjo5kPrED460n4iSWkI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Here you go, courtesy of AMD:

----
here's the driver and patch and instructions that we use...

# On AMD Alchemy Au1200 eval boards, the SMSC LAN91C111 is the
# network chipset.
unzip -a ../linux26-patches/LAN91C111_Linux_V201.zip smc91111.c -d
drivers/net
unzip -a ../linux26-patches/LAN91C111_Linux_V201.zip smc91111.h -d
drivers/net
patch -p1 < ../linux26-patches/smslan91c111.patch

----

Pete

On Fri, 2005-05-06 at 17:12 +0300, Ruslan V.Pisarev wrote:
> >[In reply to "dbau1200 ethernet driver?" from sjhill@realitydiluted.com <sjhill@realitydiluted.com> to Ruslan V.Pisarev <jerry@izmiran.rssi.ru>  06/05/2005 16:32]
> 
> >>  There is a smc91c111 network chip on board, so my question is - what
> >> driver is suitable with him? Is it "MIPS AU1000 Ethernet support"
> >> which fails to compile with "error: `NUM_ETH_INTERFACES' undeclared"
> >> (and it must be?) or something different? It seems that I have enabled
> >> all other options for ethernet functionality.
> src> Without having access to a source tree currently, how about you grep
> src> through the 'arch/mips/au1000' directory and friends for the string
> src> NUM_ETH_INTERFACES. I think you will find that each board-specific
> src> setup file is responsible for defining it. Either that, or look in
> src> 'include/asm-mips'. In the future, make sure you grep through all of
> src> the source to find other possible uses or examples.
> 
> Well, problem is something more complicated... At least for me :)
> 
> NUM_ETH_INTERFACES is defined /include/asm-mips/mach-au1x00/au1000.h
> for all machines (au1000 au1100 au1500 au1550) except au1200. I dont
> think that someone forgot to add NUM_ETH_INTERFACES for au1200. And
> even what it means? All these machines have "on-board" ethernet
> controller in processor core, so I think there's no external chip on
> development board. au1200 haven't internal controller and has
> dedicated chip on board...
> 
>  Furtermore, I found now, that Linux 2.4.26 distributed by AMD has an
> additional option CONFIG_AU1XXX_SMC91111 in config for DBAu1200 which
> controls compiling drivers/net/smc91111.c.
>  In 2.6 this file disappeared but we have drivers/net/smc91x.c which
> configures in some arm, ppc, and superh architectures. MIPS knows
> nothing about him. Is it the right file? I suppose it is, but...
> 
>  Am I first who put 2.6 kernel on this board and see that is there no
> drivers for it ? :)
> 
> 
> 
> 
>    ()_()
> --( °,° )---[21398845]-[jerry¤wicomtechnologies.com]-
>   (") (")                 -<The Bat! 3.0.1.33>- -<06/05/2005 16:38>-
> 
> 

--=-Prjo5kPrED460n4iSWkI
Content-Disposition: attachment; filename=LAN91C111_Linux_V201.zip
Content-Type: application/zip; name=LAN91C111_Linux_V201.zip
Content-Transfer-Encoding: base64

UEswMFBLAwQUAAAACAAZbI0x2COC/s8bAACTSQAABwAAAENPUFlJTkedXGt3G8mN/Rye5X+o1RdL
ObQy9mweM8rJOZRE20xkSiGpcfQtTbIodtzs5vZDMv/93gug+kFRzmzmaZHVKACFxwUKrX7POTe5
nY/+2803ceGW2W6fx4+b0q0yX7jfpln5W3z45HNXFfjPLs8e82hbuHITlfzIffV56pN+z+Hrp3iJ
hxZ7l2b5NkpcsS9Kv3XLKEkK9xbPYAf8s/W5T/YgmxbxCn9ehfWgB0LZGisD4YGL0lWbmTWIuSrF
c7Jq46NVnD7yoRN8Fj+B2nOWfz05B6VhUmSgXXpll+s/3t24hU+yZ9eWFg+Ba37/IffezbJ1+Rzl
ZOZDhr2iMs7SgVtUSiNOizJKl56bLrOVUY9Ll/u1z6GbzJ1y3U2cVt9AQyU5O7Lj1ot4GVbjuedN
5qJlWUHCvXvOyXdcQo5+7ze/+Q2JFW6e5U9Rsir44dtf+ZcSwDm7j5N793E0GU2HN+7u/vJmfOXw
72gyG4UV+OsXsAJx3fuB+2uVevfup5/ekYS7qm3j9OoMH//pp4F82dVZR2PjdMlzOP7X739yc7/d
Jd7dJdHSD9ysiiHyjz/+MHCXWVGSwOehcz+8f/fu3dt3P/7wR+fuZ0PQG8Ee9xl4g0Z3Pt/GJfUJ
tVO9ajBxUeYxDsw7rF2AnS2/jH0RDAyPJjDXFCa8ypbV1qelnvByE6WPNCkcKBbBfBwOJHv2q3AU
ZP4u99F2kXjRDHzHB2qFW2e524J/VwSV8N+VL+LHVNkso6/48Dnau31W5f3eGgpcZVt+VWzkAYgg
fIgFOHcp3lLmUQEmxYx5kj71Obzmrlpg737vxsShk6Wlh4vIZo9VlEf42ctm7nt78bt+L7D99i3W
bMlqUeVetq0lwh5cLLLSIeOykABRnDsJJP1elzsXmIt2uwSnwO1FR+bsB27X2NCboqXGVASK0r16
TIhGdBySrspNltPHtrAIrOz3qkIPElydzjJ4mz73msF25JOoJ27a7wWV38SLPMr37hXhGBgQj87P
nHvIKsS9VOTdO2NHDiCEUBxklp2r/XzZ+NQ9Q787H32lTkS5gZsBvyJXEl9yigQ12EEOaKH93i4H
DxDzFjsc5654YYbts0UAA3f93iZ60qNu2UnLmdSHXnDoTs2K8kexCWoMKrSU4OI1ibvnuNicDerN
IM7SI2CDSpUvvYZS2BPV9ugZUPu98CQMGD+3nuUis9qOYWaSqBy4XCqfQiV1qX9WloP6L9ScAr2v
KVJCILzKSLQgaSi7sEOaZ3y49MtSPUliYSGHk/qWRnNPdS1pUJYnoZFFvOr3YLmMWlSpT8X5bR8l
ReZp38VX/Srj4eS+znW6CtzM9aHOPvDxIolKob70eRlBaKzYMcku4iQuYwtNJK1q7feOnmxbnwPy
ZIewzVbxeh9SkoPf5M5/ixjBB2HNUYJFtdy4KGgeCtt4umG/hx/LWMSWOOLWHpRkqwqh4TE2U4Sd
xKCVQkOMNY0qRLviVo52e65uJw8f2Dae2YvDDWqra1kavmXYq60QhIYwjpqTYgPjwKJtMAvkHMYl
Iaumgz/FkKg+IvFqf8xg4AblxpXPON3S74qf3em7sxbu6mofNtrvnb4/gxrh+mYxrdT1vImhW2qq
kC8T/wjHl5xYSBa3pDjonDWo/k6SlBxoe0fjnMBpIIfiI56dRFaEYhOHhAW3VLnav/hnsH+zPsYA
aN6HXC2YjcBpVdRnopE2zUAgZ5Lay54iYTcX4UTGXcsUIEkBYoVSBcI7t/FJoZliFxUFviKKeAYl
CyFF25rAsR0e2HkOdiK2FFI/t8xwMnEaAYsWmUnFHARlAABsJdvm2apaKiMBzMUwVVJA0E5oAjyM
FjFEA81Xb7BiV5WSgILlfOCKZD+Qfdphi2yVG2AP5HdsRwgNjZZIMaKCkD93/L5kMoYNMuxKXHnK
4pXwsGLczFVspLhgGEyecNfIdF9nV0oSp6v4KV4pNs0WEl50lxr4IAikzsNOl+J+kqY2LTr4P7KU
L5FAzy2awjhoODhvMSNR/DZaEfW4ZeIj4xFaCDKpQy5quLVSKzUje2OwhCkAH1P99bpIcNx5A9h2
tITamyWBZZBS4ymp0nEgxaCJamb4/Z5a3lJRwzojPgTl//o1QBtfz0fTzzM3nFy7q9vJ9Xg+vp3M
3IfbKX68exhPPg7c9Xg2n44v7/mVLPx8ez3+ML4a8gMV4YdzLdmOICuzTtE65FDQw6rI4gWxJA4Q
KC2ijpiid4TgdRXUhKNNljD9FNHeIPEWqBXqb6IJtNGUY6rLALCPA5FzVf/JnXJ4MtCCDCGqqZ8o
gaSNlhgUQMvByJ2INItIPVy2DuRwOB650PlYxG59RSIkLHUijg7GJmSU/UbmJHr+2fw8Fm4gPTbW
xaY7s+4OabfLcjEIgR2Qx1ioKxAKweDftp4iROM6g68YUKiCTLNkAm+tokfq7fQTQiZiwxp6HtRP
cEsB/cukIujnHllF0wcOtq9TBbE8H3fS3v+EaHXEKG+eIqEvWq0AHsRtCneCzHIijjNE7H9SKJGZ
donDXvOTjqACPwWrNshazcTs4kKjr6C4qmRrQOJ1AfLBZiLG0TUMpUpfnIAF7ICK/GpgCE/IIcIi
NGTb9iMAhg3Mz1Li9LVsyTOWBCHxNS4lZ7oXJtfvhb1PER79jkgtlZIGgYzsLTxgvcQziHqE5zMo
9YuCIVebW14RpZNYwX1CWqrlZC/Eoti7cwU80f7XVL4B2xmhN0UH8/Cg26CcaDtOxV+2SBEVcBt8
ESnAN6iZR5kWu3hZZVWR6P4IQxLnYcj4ZEfPR/qBIIIkjM32KhIJnmfByORYJlG8hWrAd8AHF+6r
9zs6CE3B0GC/p88VIaMRKrHM7oRHLR6pgGhReGvfULyaNgH6SmFnU2O24EJXf7AIkSYEO9sIRJIM
x6wor1kuR1afllZKgngN8iAEb/YFfCUxK1f3DgWfbmaAcG9kIgOW2c7CDgWvoVQLrDExfwtFfoDa
ZkTvGyMyQCg0Vbb8uO2ESGoBr9/TiIcllaTOrbL8apAeWLpVm+1gU4n63QBpsd8dSTMzE/Ad1L6A
Jx8xUlgJkPrWe7UXFaTwrWT/syrCueisKSCWUVVo+VGjzHWcaH5dQsWiX8hJjzfzUyIFQ674eShV
Re8aiZREiEsr1mtmhbrqPLCyeMGKmCrVUBNuaQ0qMlezGpkBn3SekcDla8FreVnnfvmscKFnehgb
7YSViDxIb/DZmlVUB38hbkS2TURVBONmChP/jPNVQ4a29BpcCPgg6GB5FkB/fQQBDmjDGAEGUHil
LR8pLNj4yiNmKUSfoAEEYQTfVmWpCqXBypc4sZxpN0RoegjNUJ9vkRRcGafGErtX+QrZOGcMkfIS
/MXMADnPBpCK5m2mlaZZhaDDPqNlavGRTih0RyNhpBTsk9dLp1MCYVQ/g4DWakMxnzBO6ifOXN0C
kd6dxIBWPaDmH1Qup6YkDh3IMq1PkpDg5LJAqubMPcX++SBYKpkGD56Ovi29BLGfmYM7ab0sfLIO
Tc1wEOBOacjNAPN+bRF6BNpzSDt6H2hk60SlWqCXOOJ/qzjXto6SPKB2fiaAf269GFm91SaF9Pws
2dSmK9s2ziIVLRAIIQMWRCglXeGtmyNqYk0qzyhuetVVB5q32MxYkJOoyFKQ61ywtPEJFxcezkiL
4w5FgIdbqPqJhVxJt2j7pJ4wsZG47IAtMumMN6JmzH21BOJYB0GKO1AD3c3Z3q7K+oFOMqCURbRt
aQaPSzSSOlWjjtY0cdFJOEhJBxlHAm4boFpKUyKhrLSnQmCyRmatBe00N/0VLRQVKQT8jNLjG9vv
ZgEoA3DCuW0UQGkliUS7K/hACliVLPePUb5CmhAz4J1Q5ypojkcHrbsJcivt/rKOo6YsyVSEUK32
oiDborRWdOiiZVYc5rxIAVQQfrWngHUXDoe1kYKj2UsKI4j2zedaRG+sKacdJ3ZEkqMqbxVf7BMv
UTv7ZV2LFUfhggg+TlmVxHqxxCtEFz0+UlmBshVMKgtVc4xUv3cIzCRuyoffASxn/DlyT1lS8RZh
zcq5KLMcZZlF+0ZIhctNZFrkISq2+LNoKgbOAueVJPjj9xH+oRiHEkgVquk2IKX3Z8xg2eJfbNOE
ljuOcVmVEoOI3o5k6H5vFlzwnXDx3gngeg1vIT6wG2c+ph0SqKENtYZLpO0dYQ2suT4VfpZ4yYW5
9q8lUW7hKQBbb5nvI7l3E6zV1C8DiwPBkVsNiu8AR8tEXZHkqO0UlyCXbaM8hjtUod3U9CCZkhS5
XUCPgxZ6eyldVDuYAPWBe4qSWAlCcwniNr1ZWm+ksfdRLpdETUUiWEqixH5gON7AVsrrNG12SxS1
RL20K7ZQWjA9+jwAdNNe23gHkqj1BJTEoeJbefzwjDqnISjRcvSvO4rXT8GE+Y+OYvmaocUp9aDR
o1X4CqC13C3nZAjh4BrsFbmJZaQrFyVgJ9U4F/COXSNrq2Et/cmUyJUhFGXfi+5JaElIViSBmsWy
hcv+vTeLyA2gjWoDZH0P3eTaMnKzahFSx0IPgRhHIE7njm7dRBpttSk7cjmpx7KtkysXyYWgdYS7
lR20KpezH6TaaDOuzb46GOj2TBfYXzcNV0EvOMPn2KVioRU39Q4qw6QqtKaJiiJbxqHVBoeI6AZ+
HaeSXrRKswc0QufxTm+4V5L2QoIjf7F14AQgsR2fJHVK4sONUBD0EwzgiaonEARc2nk5eh/g7+CF
SG3nkWtGphRr9cmNotxRutA+qmFw+7lT1v/aizTS0NNCKpd+j8d11rjFNvqX4IQtrFvQ7KkKSabb
IzkFA/yZCQm0hbiida8N/UjrigG5qwMWWVBtlQrAEa7rvYCGFexH5rDSzu6qUJDA+gWqaG1APNby
B14TWQdOrB4sQm3LpWxvEyOCqCO7Gxez2OlESrkJ0ZqSEeMjZgunBxReGGLA6IJehRq+qKQ6KFoQ
t2UnnejJixHHLu7jphX1Y7vEty7qdoeKy6+OMXHQg2opRK8pnPufBlnQorS7pA0gFJDSsFfI24Y3
HcRB9EezpS37bzv2i6X8MjwQIn0L0/BalV0r2McOEggcehb0mL3KwOv7S1zlnZYapFxTRRVTRGm5
jikm5oF27l+PMNbv1Y4Z9EzgLfdRddDVTpgoJFz9yzEzedRwrtVxrG8Aw0xFXNcIRcOaeJKcFisj
CdKBBdSTvGbDP+sq0WCTxBw8M3D4ez3CUB+2K1aa567sCAmlxux67u22XK3IpkEkCtc6IJAWg+dd
6iN7Bdob7t4rW7eQwf2VA2KLqSwO71t0RohVcxSKulyvCTfxIrbJuCR6rmcKrNR8KZISQuLJeFfO
QR3lSQYC26j84Krg1NqXr3f0z7RbxFvPZW0/ykGY/OucdSmIl5fm0s8MI1H/n6tF5bkWQGuDliYP
yqN6DOMP53p9U8Zbb0DmexXCvxObD9Q97wN/MldgpR28MwQ6eLNdbNtXWd54dbdR2Ro7CJzB3SVA
lXK/3oxYdDUX5jssZMVIG9YXXVd5KXdlnZkYK+GaDv4bV9erFnQtJIiNQx0buV4710Z941c2RaN4
CuUx/rvkeTUeaXdZrTitorwo6P547sZrTf+UrIDP1ncRzBB56f5VrR6lTahgplXh6hU455nWTEg+
rFrbwYYbC3aA3Knefm9jm420+3P4b+WLs4GAmGCSAqBFnWIStKJTm9KhZMoXcKIgFxTdYedWDD8L
yZxjivAa7Uy09jhwGbG0vTm3pBI2V7lznTtff1jHQaS5zpZc2b1ByAzCF5wugqUV8bZK4Ldeb6nE
lzPkl0dDoU1CaIYopfHaDBp6HKq0+lvPGTx4cZQC14ORvuKKNozwcogqqg85eNhzViWK+nTU1eXZ
HtXF/q1MOrScvYUlwjYMiYqTMxkWyurrPbvWWSFhLDk+wlCd1j+hDBXoAVFUSo1GUpDY2CqNAnwF
HS+gKMJt7W61s6AsW3hxCITqnCmt7jDJWX9HgoD3WpdNL9pc+OPGJwTfWlBDlCpVJ/WCCC05Cw16
57JKIoTgOF9WW53k1rC3iJImuPs2/dY8LehIzzPc4YRVrWuQ7gNhBDR1dp/f3lhvcsedbt6uyiWw
HWnn4YgqS+Hyk4YB15qPkS5fPR1Lu91bX05agWHG0PqA2oKIy732z0BF+ua69KK7/SayYogitnjc
2TVjGPeh6I+50eQD3UnRzmFrrRBaN/S/mJ7A6KIwYKeTI8EXdtL/p9qc+yzn6TMOkNeDQ/3eI2dO
4OgaiWyjuqJ/5lRBLveg4O4lU2wcB+OXeGbVjAxTWqjPUnF3PCIZkmM3y1bFx4lEferC2rTVLmyv
I1+/W2WpHsMKqWkl87EbSY3FRqyHyFEhQKfrULMbOGwClLEpUasZ5AjB0TKlBuhNFhuCnB94Udto
ZZKPzHIj3iXINNazVZkL6MI/mT8s/Mtcpnm3aHrSTRaU6uNP5+Fq77DrwVGYqknQrVuZZrJD7ivC
kKuUVTmDmZW4NJvGFxbaOQ0vXdT1vobvFmx5MfPEcCmVW9Hh5GX5oNE+Wq20h0F7wME/eq7fbeRK
vyNlay4HaU9vAml2WeEbaQY6XxqV3Wfj9hsP2iBKBShsMxJplKHRpCpsC79izkz1XmwZaf5thWmU
BhlcmtcyhQb7FpfwfJho6F7aBegiW70YfjCQ89O5TOu8OmZPdYXJkNw/xXKNrEfPOe0nfQOlkLEC
bvXKuL0CBcJeuhf+DxFnlK9NRJxJjBQwIGbgB//FLs5lJl8DLiyLrmyP6Gsg5BE4lRMVeGDlYWuJ
hn8djZJNdmEEVCA9bD+3EU5B5EaPZ8YWLvuZPEucdgXJGTDDirTaLnzeDLnWFbY0iNZS9x8sflGC
aAxtTQFaNj6RuM7BsjyQOBk0VaDk9TA/0jTq5fNjILyearNgV7OV5ZZEXGevcNC+84pVv3fELl7I
39yhqB72x7RweEW3r2dsslAehGdY3R7n5+i7J2HK6ofzgDbDKG3LWwRSvJiPkQk+Dc2dYdrCbhA7
Pn0AxNXq5L6aLue7yUOSAl8RIOhvCnKDknWKqC9F28Hv3x3AwYav+e+FvKqSbT19rpDWrm9amEU9
w22vozDJifqlIQJHhPmvGm44Cf+YRYm6u/hi/hQsULEDwlClo8kg0HQT5KPwTlMjulTgCky2WV37
82UnnbhYIeZYhqmfedQIk+zlzO0dr8mt+zKcToeT+YNZwrtzdzm6Gt7PRm7+aeTuprcfp8PPbjwL
473X7sN0NHK3H9zVp+H042jAddMRV3Socdi3RQHLbuXn0T/mo8nc3Y2mn8fzOchdPrjh3R2oDy9v
Ru5m+AVKHf3janQ3d18+jSb93i03+DIGR7P5kE+MJ+7LdDwfTz4KRY4UT8cfP83dp9ub69FU5o5/
h+3lQXc3nM7Ho1m/B05+GV935ToZzsD5ifsynn+6vZ/X/FO+4eTB/W08uR640Vgojf5xNx3NoALw
NHXjz2B6hG/Hk6ub+2sZar4EicntHLqCcOB0fivqCWsDebCDDfq9z6MplDiZDy/HN2NsyjHoD+P5
BJvIsPRQmb+6vxlCjvvp3e1sxI4Q1Qgq0Pp0PPubG0I40+7f74c1JagYRD4PJ1dyXAfHSYndw+09
MwpEv7nmAlGSrKCyRu569GF0NR//glPGUmw0u/88MqXP5qKkmxs3GV2B4+H0wc1G01/GV1RFvzcd
3Q3HOATOfE+nJHM7CfHm/TkPEfYy+oXGcD+5ocjT0d/vIdQRkyCV4UfYHVXaOv9+78sYDPCkDq1g
IM/gi8YKHmBQt+7z8EFnzR/MTshqPY3eNQ9YR2Oow8tbKuISHI2FMbBCrfCkroefhx9HM4hdW4Ns
biPyAze7G12N+Qd8DyPEmd+oauBSf7/naeIDo+KGOFaRjiZpR0ePpNVNgrFg90MvPW02P7BEMZCb
2xntDtvMh06Yxv8vR1w+HU2gM/Gt4dXV/RR+xhV8AvzM7uF544mcTL9HmcW5x9Pr4F2ibPdhOL65
n76wNmx9CzWSplhdfSq1uc3OBmIKbvwBm119sjN0HSd+cJ9wHpcjLBte/zJmKNKNQAZ8jk0vt0bC
lGnhjtEOTqOPHHk5QV9t4KJPOtM1lJp2Lq26uaAEfPjAWDwBLLIsWKg9W+5cIfsm2Q4p3JCTjuUw
Hktq1fdzSGdRo/9HedOF8yooYLQDVxV1ftLi0Gp3FhtsTUjze8PqROFRXNTlDF8F7KYKzZL1K0oc
oep0TwX66NhsfXEdmpPmrfOm81uWkd13NTCqnkwOUFPbGtCKFFJFtBbxyHX9+DaslsFE6kLmhOxq
h5eTIhLv9vV1G5t2BI548ppUBfQXBuqa4WkZNSItIVJspDcjMDBMICj2P6lRwwnqgNTaYW6XSfnE
3Z9lAlFkrfSaA2JSojVhQj3C+WeqVSiUWfNCn2nhDbBdtA3EFyhb1g7IIBKepdLUX0Nw/hcldnXw
Avp+jw2EAqGBoKO/hI2ltq2vyIsuRLgIrcPuaStgbt6MU0r49OjA6rGXsJtp86KDM5spw9cxVfOy
iL5+H3apgW1mowin3bHvs5eY+/w1LbQvha2M23D4qDRtB4QGJ8OxDmyYBdVQQAAMTgEFXNQvmtht
pfSQE5l1DDOphOekcZjLoeNfkcpnXuxFSXxH22s5MkJnKdOKWn628dtW3sx4uPYYy+ukw+BG6za1
0egFq2JY/vdgsxI4/J0Ig//8lx/wb/m9Fuw3tGdY2KLT4CwjD/rSKUG254BdnqWQip62i1A1ICDG
SWiutlzyYM52EAJneIUmojrzejw5ib9qmO33ZH4TCyVmFTJakrZJ0ad8Pf71MQU2f9KyIFj8H34a
HHPxroO/fHyJQsReqh1ezm5vgFJuHtpo+0Lsw0zDlXvY+z/ljd7nN+ctNzkMEk1qkkzhE25E9R7E
DCVh75DVPalQ0V20N1y+abNyHmZrNvsdS0W5ZXP1KHvgUdionzdrDm8kd1+k6ZSir758d7uWCx27
gmk2lHvsgn3UvfRLeOcn19Mo9KRb0Xrl6yhz9gKXXgxITOAE2DYD0bdL8PBV+iRbn1ZQm98Wb98y
yktRXlSx3jHXvx9BtNPyX5kq5Mvasoiuk+3x4Gn4DQH1dLU9v/X5GbfbyzBcwW5AojcsqY7q8+Yb
y5tUx+horxydNC/lBJwSI5Kl/KUChb6/+skm8COOeMCPL3TkSx6iyYa3Sh6yfbbapz44PvPmYl/v
pXNMDQ/iMcQyFp53oRPk3D9bVv+G93My7gj/LPRd58LZMA2HdYqzul+H3f5KhtynaPnV5xYc/6yz
LnxDHgYz38P1svQvA/cO2C6PE/n9LoJv9JsBQJ0v4vCC2y8xp7GshfxKVK6bN3Zv1TRNaEzts5Z2
ifRIwgvC4ZuivunL2yEq4o1xnvHWnEFIfilH3fnRt9I4+M54JHlB8xlP3XgBJJFxtPaWrU5+eEmf
ucfIh+aURornMOwa3nxfAQCGF4aO/KYQgPCjvyrkSAP1/wBQSwMEFAAAAAgAGWyNMW2oF3V4AQAA
eAIAAAgAAABtYWtlZmlsZW1RXW+CMBR9hoT/0GRmgYdKdMuyaTBxiEqGYkS37ImQWqUZtISC2/79
LvVry+xDc889996ee2roL95y7gXxyF9qDrJrWdqyJHbGeP2Fu+17Q58uhqupBmTLvNRaNuMkqzfU
0N3FumHvHh8gXoZRFLvhbOEHnuYY+s3Ie15PGh6PopkbK+h0DR1qx8FwEmlar+Hi+Dg7BjALR+vA
OwSv3jLyw3kEyA3nY38Sw5inDpz/mfjceCLeI3cVgHD1rIWw3zLVOhC+JVkGt6xKRipclKIS1XdB
JcJhF+GtyFmFt2WSU1wIxitaQpILfKxPMpZIxncIF6ygZ4ryXZXikm5qAsmcFLXDWiY4ZDWiFmvn
BAjCRwPRSdLBczsXmz0tJRNcttNfipVlbmNXy5QpBfFsiz5TRlKY8Md362NHCBoge0P3Nq+hsju4
7fRRlVKOKEnF1YY+opmk13lFb5nSIHOizG6LHjrHxNA1aHKtplX9q9rxwiMsLkgY+g9QSwMEFAAA
AAgA5HiNMeLwsHINFgAAU04AAAoAAAByZWFkbWUudHh07TxrcxpJkp9FBP+hQv4wUhw0DwnZ1sTc
BULIYkdIWsDj8SdH011AhZoupqtbWPPrLzOrqh/QIHlk797uHvOQRFdl5bvyBePhuMduurfvW71W
q8UuI/HIo2plxB+FEjJkbafZqlZa7UbrpNE8rVZ6cvUUifkiZke9Y9ZuNlt1+N8pG8du6LuRz4bC
i6R6UjFfKtaT0UpGboyQjsZw1PEmhNb792ds+sT6kXhAIItg6cLa/hhWViuThVBsFcl55C4Z/DqL
OGdKzuK1G/Gf2ZNMmAfLI+4LFUdimsSciZgBKg0ZsaX0xeypWoF3ktDnEYsXnMU8AsTkjP74cPuR
feAhj9yA3SfTQHjsRng8VJy5cDC+oxbcBwSrFVx/heePzfnsSgJYIu5nxgU8jxgwT7PNnmDA1ZgE
rh65MeIcMbnCXceA6BML3Djb6JRRnRHnMxES2IVcASkLgAfErUUQsClnieKzJKhVK7CUfRpMru8+
Tlj39jP71B2NureTzz/D0ngh4Sl/5BqQWK4CAXCBoMgN4yfAu1oZ9ke9a9jQvRjcDCafAXd2NZjc
9sdjdnU3Yl123x1NBr2PN90Ru/84ur8b9x3GxhxR4tXKHq7OSCzAO5/HrggU0fsZxKgArcBnC/eR
gzg9DmroM5d5oCzPC6tacQMZzok6WJpx72cmZiyUcY2tIwG6EUu2JcZqJZNjjQ1Cz6mxzns24cAZ
zu4D1wPpjRPcfnLSrLELqWJcOewy1myD0dRbJ823jH0cd1PhzQRs9WQINIZK8zkEGSYeHqJqoIQq
ZksOsvDhL1BXUONH7saKGERMVEvvPQBvOR7zySiBw8iopfuEFGl5CyAaoesVqXQj7vr6kcEF9iJu
2rrZJVdeJEgFz6uVX7ZfhgoDdQGmMOWgL2RPqCzAxrWMHhgo+gOPQh6Amzh1WBfoQOsLlCwQX62g
jgPF6AFYsvLxL0spu/N9dvGEhqtUApgOluAywJvEiD4SIZFeMMgpkoYkgUUrUv6aptDguSSngrzx
5HKFEsjws3YpA+0H3JBQrlYYSJi7oJno72JCiLBc86lCkR8t4nh13mis12tHLZXnAOxjwt3QZMmR
oSZVI6MVm/gYztUGDagLbhC4uwWwJQ9EtAVSJLkgyVyJeahFMeWWYJ9UKZCuj78qsB8QWULi/7RA
hqySOAaEEBq8BKICAMglGUYZOwSYK6mUmAag/LAOdQA5+8RjrQtIO/dJr/Bf4CYil9NEcEkyDJ4I
G2QOGjXIVB+DCuW54K/Qtj2QxpwjkwxeKISQx6RiBh7gyaMZmCIcM9BeIqWZdEA7+Lw2ImoHBrsT
xE7aLTUWJSH7aek+8J+YXoiLcM+NtJZjSTnHhweA6jlyLFTAUZbapsQztDMHp7RyweVwQFTBpoMD
IX9pfn3z5g3sO9c8nqKiub4fcaVoRfTHL2/eHGQL4A2EeBDKtSviX77ik4MmqZuyF+ygccdczwMQ
7Ghw17seXX5muBpXgFSOcf/BQYs2zVzQULs4lKx8PRLfcZBBoJVyzdwklkvQTo+Eh+xAtQIRCDcQ
f+rb3PhkIx64h6ZSxvVkZUQIRNLzmUSICCIQIfnfBo+9hlZLBcYUztgR3Gkj7l8DkLdO81gzHE4C
lQMP2Uy5bUDDS3PcPE7ZrLmpyWHpdcQwnli5c22ixh7wXOtPE2VcFui8SiJCkq4dMmcClZM3eXZz
jRgq4H4G5Y5l9HSeHk67ktwfns8agZhayhuf7z6OvvQ+jkb928mXX/uj2/7Nl9/6o/Hg7rYBup/f
uWI/pSewNUQZmi7CBDRJgC/4qZFD0clvXsg12B7I5hz/l6OksAiV2v2vqPDYLACjDinQIkZpb5ej
HjzRioPthZ4AThyBzPCc4yInGmoqwgashD3aL1YrXf/RDT0w3yu494DtqtQT4srBTBvHjQiTr+xX
beJrOCn1AObepyt3JuaJiTitmvTubq8GH77cj+56X67GECyANpv3xp/HvckN46E71a7EhEWWEVbB
IZ54REYzBZETBiAQ4XpxUK2gFPRdps0MVZ1/jZElPpsZ0hzkotIiUxSxTtE0ErKqaqUB0L0GQAQW
PYJ9LH6vGTn/zoQNH4z/Y2GynAJCxv44Rp2gLwzvTAciUogy+VcXQ5caxj7EuPGwZ8J7Dx2IAUne
WYbchpQ6ZtcsoG1FEm2QGUjPxUAUrHUL76YJX4t2r2KVKiwwMFkhrhRU51wI7TRHatUuf+Vil2ql
nn/Bw/qrXnC+CGcyd9h9BHzHaxSJQJZnyGticmGni5mF4jmtNy8/wxhBcNdbINsNwWvUrs0DSRw2
y7ChC+IWLUu8r4aETjvkcwvpE4pRgWKAr2oZ/Va0CK7WuQRXToDAILm5udMkcJsEQ3bJ/hVgP+j3
++xds+2csF5Al3r7nWMwwA3b8PIQhNJopgpyGKkV5/4hXTqH0cxPVsHXQ3Y05aBRx9vAArHEHAhz
Ic9duVMRiBh9EfJuGsEF5uElaFx2xJcYh4F5OtuQCONDw8jDFDPJmrQXH9TzqBvz3gakczZyKTq6
J4EiVfQXUsS/Wj+AkXIE5sL9Et0hvw92Shfwcgl5Lhgf/E0qV86pEsI+mzxZR1qEzaMbJFzrkc1X
wB4xBLfhD3hXuDpLkDrkcKsAT/7b6twhEAkbl3qnznGJ/cazpLfXNqxt11eCPmqnz2duEsQZ3gU5
tYwNaB7b14hrrSXheXGCbpsWGPOBkOTBxtTEAfiJqVMdXaOBqJm6B6IRZgFkN0OzBUzwBbpMtU2Y
3YEHe0kUQYCMPhmMysUwHfkHCb09I49qqc5t4B5tcuOPhIJ2zYSaVTyV005DRT7anixKDptyCMGF
xLj8UT5YX27ZqEMCmxKlvCinP5OjTlRt2Ja9n3egkEA98pTB2xCR481mxnP8a7iamiTbzchsFRcN
pyu123AopyyxndQA15ueo8SHGl/sZOZICa/2fOl1aayOUkaIHOJIeHE547KiHYIlCqzqUFq5uYfp
IHTrzi5duWniuxe1cBWxYc+afYDKrdswVpAEjT5v2qLVZ20eGwpt7dJyxOh2ieEUlf2bdHsbWs6v
buv2fuXeBma0fYc/yfsGDBgRPTdbWSLYbOvCDWZbLHL2KnypsWX385YJ5DW+TMYlF0sKLHPpQfgw
c0Vgl9AVnecBond//Tl1o+AyXYY7MJOjDBfyS4eX2LYuFIUhXE26jkK8Ez4a1nGR6TlfUQYHorIg
x0XCeymEXGWLiuGY4gGcCiFKSLlChMUDICJ18DqusEWX7SO3qzDlRkRIEDebNtxEDu/AygaJYwgu
PKx6X6F+XWolucspyWRR5uCEMsUoiAB9nV2QTmhO5PQBskTPk5FvinulZpQ5N196yRIuRjr8eAeL
Uo6UuMr9LNIcyfOIrxaBzGS3I5BmuGbqeg82yOnfX7MpJEcPGyhuY7S7llaOokEojyNkAp5MjWID
R3xIKMKSgLo4351r+vwCRiKIIbssx6h4XeFSyGl09GMq1dyf61qgG0UCG1CbCKm0fdBqsylWasUS
E+v9hFk6XnrrGCoKhEWcLyEvNq9CBLiEFJ7ywmkym2EFGrKL6CkXyuHmGmrI9Akw0QBjGefgFQDC
I/AEO8HqknraBNpjNZtnQnLh5tbZM6nxYC9NuEAgM6UyHbznC5udRdykvGU31E3/skslWc1oc1Ea
aaRlGaqo93+7wGbJYNxlU+lGZUIBaOB26WrFiNgUK+YRSpIyIMUCF/JALNUcQlxwuNMZ0V2NFZkV
kEnyxeahXFIqFyXsrVMoUBVev5E6FF43yJVeypWRYckuCFROSH958WsXOAZY0+tGzuEWCtjdyAS6
FPQhZ0z8R7egz2O603aDa+kfI6549LhvYduspxj6pdBP9I/87TGUPnhIXWTbvfFU/5hEbqgwpwdj
H+lWIFuBpwWblh7Z1h4YHf3D8uYGUb58FuUz/SM9+cXHvdU/dqL5UseDBkpep5Ma7DS36bsa7MX3
NdiLLYN94rqNsGmxV5evMFh2pDjXEfHxi/05spHYeqLZ6i3EKuKPdlPe9+IjYJ0ZeyhWWVO/6uja
9QR4h7fWkDq4MpBzXaHR8J5v6e2Zr6hWLhK4hHTVSItIt7Z09XsEf2Oj5J3DJuYplZzHSzeKLwTQ
cjvo4ZOaVo9qRYRekPjc120VCGt1hP4FF+k3olX6ez+KZJQ9uid1vpFKZe9NFpFM5otVEn+Z9McT
zZA8OdXK+0b7tIFkVSs5PcuK6mlL2yCfNn9sqmBLnuluVMxqxXOXRkc3urrY72uTVuv+hD5u7nlw
o8pCs7FaeQixIzJN5kpfo6AcaXNYS9ugk05d6ABqENveKAYY2IGsVpaujymXL/Ca5qGH2RIyB+th
BMr0SOAMXS0KnrKmRda9P3wAVA+BPv0o7TZQ6pkxhx1hXY16nxBVLd1QAzTdZIKEgFi0WlYrZDv4
Vu9ydDc8drQwKDSP17gb9D2kpivWcLGyTLzWrQqwxkjFhHbIuuMJu4jcR8mG4/qE3Y/u2Fm72axV
K+jVA9buNJs9zaC06e+yewiARLK8jyRbNzDFnkckmHbn7NcLdtMGZwE5Ro2dnQ4pTiHZ9C/v2OWo
O7TVmrbT+XDB+oPLPpANvoW0xrE9BsXR7VlSCFs2x/kQ4dnj2WCAvd6QepgxOzlrDq//LOJareRQ
YOP88SdNOD13MDMMdNktjz9wiHavuicQ0N73Bqwf60YMamnkp6plkCPdLDTpjdSMqs7ck7xZWPlX
K1lnSzvgnEXhEWtZbHkpY0BaftgjE3glyMBMt2TdQ9iK+mu0YI1vF5Jh3aZAomx7o9eddBjOdimJ
OHp4mZvjtCRQgfPttwzeFAAVVM6lNlKARWI3bfVnggKHqCtyJrwP3DCNftGwcHznE6Tkcq0ysCSz
kPVnM+EJHDW41XBBwmMsJo1jOGzJwHtB9lErUoscGWAdKKRWBHk4BDa4HN+wo1j67hNNSwAsHTKh
Zd6Cr1+sJCh3DWBAiB7BpUerGC4Snl72P/A6trcGG3ukoZK9aWX3CAhpQEKCHQZrq+Q5O7KKnupE
7oK2V28ILhJu2pu7XvfmsKaXDu7tzAFrt86ckzPnfcdpnXRqyPmlqx7AKDtO+t9p1sUzh4MRbZ1d
tIDs5FF/eDfplxwNxpU//XT/6XATXETWP2bNz2Rl4/YJvU/TGGROM617dvBL6Xb1lDP+lXs0OWda
0xYAsejctKa35jpoSW/BIb9vPLpRA674BuSbiuYIcIyPh74eAwLiIOYAVc1NsSlT5qNRDTvuAQAR
08Ho79gtSad3rHHbdii12IAK7BAnoZdVlDZRthTTEERBsLs4S0B+A+2b4VFunDEXeQsyTFaIhYdk
W94b8lB89sTzfeiUnmGdIxt2e6lCpGEq9p0sMYGUD9TIUJKyBScVNvGoEBDkEmJinIF72Gyev2ue
N6/Oz7rn8LtOEy+4nvVjVLY0a6mtjc4Nrs8/Obi2Gv0K8ZHCgU1EketOTC6XZhR5YfIEjDmHGAng
mKkGiEHudUBDXcYx+PAir1b4tO51iqawxbMOLTRuOeIQm4fcf/b0E8dorOmig94KqlYVcdjdBDAL
AlUqxKxHYXrfWGDF8ZK012CbZWkrOi2lpfUq3WC32Y0tkppOFTXDU2Cme5WG7GmFKa3I6KqGrRDb
9oCpceoyS5F0mjzNNyI2adSZwwq78NzPVaGLEKKs3fE8ANu92AChkX0FEu7rkXBfjYTh/csglOJg
xfQSAO9a79tlMIxCvA4IKtPLIHTKd09ftvvkOTM+tWYMybU13Y3BX7RqvDt8vD6EMk0pNE3TcsWt
uWEVqSd6CFQaSJYgSzU1SuoFdrhqtu1BUVlaUzGRU+5i2oIDmf4OMFgVqpuq0DagnUzpWKZQiQbJ
YnUMxtksXtEtmr4NoaUbzbktKGC8SjjZSSlz0t0Ur47C6hqIiUMiB9x9Sue8lnzu6uwAVivxZ5YF
xKYCSwf9jiPl787qp07TadVbjjh5d+ZAIqZrGJcCLuPWRn751mkWckwCZjNVoaP3VmdYPNxgr6Os
c6K+cPUXnk5FWPgbcnZN7pd0hMA+mvP8o9yvX+CIwso/EhEX3sDs95m9m/pB0sLKti2UgSpEetLF
zsvYSwchrnN9sHQG3Z3hxyZSuT+rQWcOioEsB0sg9VszyANiv8KGCbvGluil6aYaXbdAF3Y4CeSw
PbJCzXxqeOE4D7VNKaopCTdL++qfcBq3Y7IoM4awuT5/YexZ/+zlouO5Tbe8AWDfxVAG4HlPQqDs
JFTBPcxm+vx7U4UgAb5ps6PNSOoY7fxRn1PwHFubO+xow1kcP6sebx3Wd8My7ej6cGgsqFqzR0fy
AtucdygT2LO+dy+3XhrQbEur9XpxbwPYHYuUINBsfgeJvzQK2Yk/nvPIC1eDrmmwtHQ2+lv9tGNP
ltFrD27ZgyHbBI0qO5o+jlF2NPs+RP9LS32/Ab9zyv34DhP9Vh9MY065wP85H/yNzHnWhc5mL/Ch
rxbvP9kJv/8rTviH+WBg+b+xE/5/H/wf6IN/rAtGN6Z9cK73/z198DfGwd/G3dbrfHCJTfzjLfL1
LrjVepEPfpmAf6APLmP3P9YFlwH4v2SNOFXgwBOsHiOEDZH9qxjl9oHNbwzF+F+KU/fr5a78rNQO
/9q1+oMzyX8HA/rhFrTRsm0XWrYuG4qv3K/TcJsZwLvp3tI+rMoqfQyV/cwurGTZcQuCkG3Tnagl
QoR3L1zF24w+fqX/mGRdUNvkp03U4ocHXtrONu36yzrNvl1/vDDjDNSeN6Rv9bwRDuCbYC0u1/9+
WTNdz4zkGr0kL3qEcsoVKNvvHeOasFml0UFcDNtAGPZNGhlAOKQeerqKCo75cC3Sn5PBZaEM68L2
0AHcqy6XsgD/Pz7WUxuBwqkeQWP3EKoL5SUyUQxNoXinNBIV6Q5x7K38ZLlidfhX6K71QsL+gnrQ
1rReXdItNUs2GaC15NCcccjst+cobj4johuqQOq2Nu4hs9UxRA7hiaAPkuZIRK0/JD0/ZOZzW/vG
DjKm0B76joQ6KnK7jW0D+Cdr3J82zTs+f2Rpg9Yy5q/u/14ysQe2SmVh7NSOjMw5Dq7GOOoPkPED
54Pe8B5VdiVpph/0h+AUGhl6noI+dI7DENSToW9pwNmKAgAzJ0qzSppKmpRM54Lws9s8zDfHrHfo
ArwajR9AdIx6b2YegLvYKrHDnxuqZb90ChExM5YAS0/+6q74Rfqp46OL41pOd46GxzRXcI9DQ3WI
rml6CGyyLC4HRcxr4pnRRPRRPT0CXBK9nUG8kHYy8w/e6gfTbb+2q++57VPOSrzirr7n9u633yE0
2jwFB+Co1xnL+Rw7Rfixk7wosq+SQj9vxrvj0mGKIr/xn2u5RlykbhXieeY7fx71wOhLvruHvoPm
oORLhPQRv6bTqEVgBj3MSfOfycPPtdhPy+NgIn1BgLl4Hfs9NqztHFzbh8tU+fTHbih2yT4kk/aI
LUNOnAN0a2YQ0ZdcrzXrNDj8Xix9+VIMY7444gjg0Zzb/wJQSwMEFAAAAAgAGWyNMWZFWiQCZQAA
dZ8BAAoAAABzbWM5MTExMS5jtFt7b9tGtv9bAfIdBllcRPYqsmWnvU2y6VaWlUSIZXsl+aZBuxAo
ciTxmiJZDmnH7d3vfn/nnOFDIpVkg64RxNY8zpz3a0ZHh8/+pJ/Hj1RXmY37ooefrssfZ2vfKPxz
lJf4dzpRyyhR0/F08NSoF70BFirjh6tAP3PXfqyG6VonoU6Vp+98V3cJBsMZRPFD4q/WqWoPDtTJ
8XHvGf57rqapE3pO4qmx7yaReTCp3hisTuIocVI/ClWbTjtgIPJzru90EMXaU4sHNfU3caDVpU7v
o+RWjZ2V7+5svxzb7ds49F68+J4gDBP/ltBYBxsHy4fTgwJpJj5OolXibIgJy0RrZaJleu8k+pV6
iDLlYk+iPd+kib/IUq38VIGiI3BpE3n+8oEBYTALPXAP7FGpTkBitOQPby9v1Fsd6sQJ1HW2CID9
BRgXGq0cnE0jZs2kMiDa8oawmFos1JsIkJnUV0r7xH4FMRki/SQ/xELsqChhKG0nJeQTFcW08QAY
P6jAScu93b08KEn1lB8y+DWEgT8AFHTe+0GgFlplRi+zoMMwsFp9GM3eXd3MVP/yo/rQn0z6l7OP
r7A6XUeYhUgFFonTB2jQljhh+gASGMR4OBm8w57+2ehiNPsIStSb0exyOJ2qN1cT1VfX/clsNLi5
6E/U9c3k+mo6hL5MNSGmGcJnOL1kaYGZnk4dPzAl9R8hYgMMA0+tnTsNUbsaZuDBHlxo05elyFCc
IApXTCtWl+x8pfylCqO0o+4TH6qTRnX58v5Sxh01Ct1uR333Qs00a/514LiQ7DQjCKenxx11FpmU
Vo77Sh2fwEKf9U6P/1upm2m/oGsUguaNWIgbhaA6zOVJeu4D8D30L1rYmWUSbUSV+pdi9gwGFpOB
ZJ6djgfg+CxSK5i/sKdDBJKVJNoJggeADFMVhUA3N52lH3pKTKSCkdjK/f1912yM23WjjWBdoP/k
jXbSLNHmSS4BnK7IA720jmIUpho8Ji29fvfxaNwfsJR7x0e94+Mzx+iZuoq1+Ai7ZZrF8Bop3B32
JiHogiEr/cl+GI9Gddg/vFex496C4o2GBj3YFcPh9eRqLICWkA+fDT4v/VVWnsmL+8kq2+gwNYJ5
y49ar3k5UbVwyA94Hig1NN3yk98q06PJP3g0jO4dP8XEMU+FxMhA0ZgyKfA0HdVTOvA3fkifCKJP
SGwvKlByMhhlYvHZco8t/LSVxtBPd2lXe5kSz9o6dxLoTR9++M4PZJUX0t8/mXDDErQrVesamh95
6kydreH3753/Bb9oQ8zj3YUd/SkXfeGOef87noWpbrIg9V3HpOCrp0UFrzW5sIGz2Tg6gZdXsfuT
p8NbJ0m7cEmlY5/C+bna5MqiIhI/wkyp3gr25iyi6Fa1q3p4UN3BofLF865bCyNbq251oGGQsuyc
uA7qNZQmAYYL/uMnIAPH2l2ZpdsNHeN0V9FdBd93cLrQrgLf3slR7/QI4RMnsuscrPV9R/U9DzrJ
/IAvgdJAL6H9KothVIEf3iovui+QO35xdPL86LinVE0kOShSMnfthCsoDWnWewrugTrpPi+A/HB0
0msGYmEYMSveP9F3Z2SxW16kdfz86OQ7hrGlRmRoUFMoaSwuNQEjySDSdRJlqzVLTACcHvW+bwIw
phBM4aQUFaGB2CTeuIrHl/Ojr/85PHr86PGjoyN1g5Pi6F4nz4jzailuK3da5LAeP/qLp+EG4cmv
Pgwn8/OrD5etHm1//IjsEnTDcZCag615eP7ln+r140dPdlT2XDK09t1J97h30FHtCz/MPlWEpv6a
Ozlmw5UHcT2k+qDQp1/DX8Mnr+jov/hLoKXGV+c3F0P6GLpBBr36W0AwjyDpLNDd9Y/1qTyD4Dkd
QgACb3vVLSPVCMC4SHgaZ9KHWJvGmaUbps3Q2AcnWZw2zsZpAvfcvDEiRu2B2Yx44CyaJ5Axhas9
oPzdMxyzOVr4aRTvkkoTftQIBiSGzTOeDpwHnqnPIVG3eXojTEomPzNvbhfZcslTR0c1+cJZxsWx
rEuDq8s3o7fz6cfpYHbRIIokcufLZvGiLnBz+dZV6klRs6yfAJc/tR5iPzeoRm6bNCOm5mFYf0Im
4evQhaOBa0nI+YrXzOPWl8/6yh/rWA4ZrfOI8yjOqnAkebXTEwXVUZ+WMMK/K0nebf7K9RHQRybG
jgcEOBzzC1dE4YIyfG38FSV9gOm4kCOM3Uk5kaY8jFDIXdbNdDg/PZmfjWbKuixBbStT5EQP4ddJ
uc6wvm8ZBUF0D7NQ7I9skgPz5hxS2MfVA3HZUSagwg05JIQP4pAwAWzilZkkAFD5YXNoqh4eAOq9
1jHSMIKzoVSTq5RiAZIIOFYoFGW+v+sksuRZv5uFlhHwIRRB5oQp6rEU7nc+J8ulJIE8MQLhH+r4
EyraDv06kV/P5df38usH+dWXXwP5NTwGjS38dSpbT2XrqWw9la2nsvVUtp7K1tMh/frXqyrb1QfK
5lJ/Y0saTkmJJQvNtWtXFeXcwlmAmaIa4dMUK0QVMhY8cWmTuWtSEU4RSU6i7ti+0U5oqHBZ07AO
oHdrJ45R7jAMWxVKLb+tL+Ph+Grycf6hP5rNZ6PxUPW+r+rz8Ozm7dvR5Vt1Mfyf4cW0sL+ttDba
Stt7PFVoR7WK4/kfT3jBHfKCKDMqoN4BF99wHqhKuHfxQKYTQPuqRUie4Mj+IoooChi32NXhrBkg
l4GzMvnqU15tSwKClk88tyUA1WywJbvCyzaxERbBhVomoZSZMysADSnEmHR0QVQt8yJt49xqqtGs
c6UWSb7lRyB8UMkpJqPL2fvTtpOsTLfbPYDoQcotf6ZlJLz9q7e97VJVj+ntbjv5tw452XcIRYri
nN1d/9YRjSf8R+LDjBoXedFIfhb6UXR4pG8GJRhJLUzFC7s3Mh44RLYiBoNwq/MugVS0JkWEFR9X
7UIwWLges9aa203qFiUgw7hfS2+Hj/EiSjv+EzEo5/SgPzm/7MOQnxTu/olNfcfifYz/OxHKOSwC
Vbm12DC3XmF8czEbXV+MhpNWu3d88vzw5EDkpaj40eJ7qm2CPP5aDneV+O4kc8VdB5ELefxBQFQL
GGEtldMCiiRURAPJRjmSknsjl3mLyAEb57CawEYJQNGxoJaV0Rv/We44OGIYBA0W+zq6V/cacZYj
K3U3fQsBvovwZ4m3LKrIwuaSZs0JjAAz7NhpC9RmZMUeSbmehSmKG+vdqTd7B3cHf84rDFRdNjrW
y3Swn7tyORvhmzl1Y4XrWHAj7ttws4w2UxKQwNvIKRw4NHWfnhIcjpgpc4GUj9uiSGNLksztnA+A
6IC4N8d5rwoxcAgi9hpxpjnHNpQdCMpWNEK33WYo5uNI4PIBuOBkNft5Phxfzz5W3DM8LLU7RtYi
ROyUeQBvMUiOVuDmQgMIASW8AaBlj57beFcIYKolrUgyqFpGmbxkEFkaPQv1KkKJyupo9G8ZJYEW
HM1jeu64KdSzgNaXRIeQoQ4sleeUVmASjsNrxesHSoWK5TOUPLQW6ypLqBAqllxIEwQsIO2Vtai0
V9BH5KK9H/J9AdZdrx96PxQ7B9L5M6KnWcJpleBLognNxjfcSUYGqHMwqZvMsXZOY18FyfZMt4Ak
3wjkCMRvA4rdXUCH6vWPthvRKWpc2ImB/MhD1I4a2KMGyIFH51hQJH5wukk+nqO5d+sENmw4c2gC
gNlXgt3fXn8Ou/0Fk2A+iSLkDbBNlzpCissmqo9Q6N3l+gpl8JDWponNcJE9hBm5o4gvH7gLyOin
5DWwC8XVnP9WCcDLn7+c/LOQzHlxXpEEisfaPp9Kxp+tmq+cPA9sQoeS7S10tpAAmDoO+U0UwYwd
MJCafUa1KRE6aKCE11gw4N+ckoqL/nQ2H17OJh9LuFM4A5NnrNgOr+hQ+znRaZaEcsuUWGuayxKB
2j4QAPdaPCKzheqwcP9y6x+Lwbk97NCulI8Fbtc5nZzA0gZLsDlQq4j9N9FMnSHaTcHxFwqdRB05
IR4190svi6sjOl4HUbQ1tPH97QHrvqpDCcEJPm0NmVhrb2tffZFTWxSEt0vErOoQFMuNtkf8IEXw
3BpCpEFEqg6lUbozEmjP2fm8qH6mUjdha6ynmyVh8NwLs3U4DcH57Q7p+qqkvspNk9rYxq/vjBu2
Lle1sYVTG/Kd5LhhrNcwdrI7toobEA7qCNeRi8Pa0LIOLE5rQ16dgDojN2kdf4zV8MfYacPY8zrH
G1iu7+oyTdyGwU/bVCAUkViD3TFK33bHfK9XHzrZHXI8d3co0ZvaGBSiBg1jNXD4e3do45jbV3k9
RNVlRfc58hQTteAjrQZpCM8vRoPh5XTYfvL2+uLJwas/qa4qCiquqOyDA9s90pTi0cXrni6SxJcY
FU9a3t9++cgv/Si11XLLgxAKi0BCQxkbpJvaPqBSjxtpyPNilD0+RaOlvXp315rbBxLGbD+pqGQg
jRfHx8eIJ4kPV2+bclI7IuGm2kNaDXyJmlIanF+5+3JX4v9uy0MOzx0pV2hgnV+cVSoouZ2nFN5Q
zp3FktjGiOmorylJsFG+jLcin8ur2fAl34Ny1m24qDq8evPmEAWotrfIlBloj647CoaV93iXZy8r
zUnpQCnbdzM+smgijHm4xBnSjMyvYoMH26cjzaZCj2hv16opdYjfuW7uk14lWH+d/ALthCQ/MGuh
l3lBZXWV784ZwwpgUlqw2PMNlYLMBEL+LvL5XgrYCupR8nU0FOUqkWGE18ssdLkIYfYbFEHQEFvP
2tYwoVkCFtGjjvBdRvepv5T7aUq+fgZ1T7d7oTmro1iH38bqSp1ty9SiQuVKEidEOZIQgZ8+FVXf
kYI0NbB1AbY908slJdgErcPPTPwl74QObWKQFSJZjiPDu4XiKC9fOzaTZARWpP8e1D4u5GMJL8RE
bVXC8zPUfw3tfphTxOX6Dt/plvApKyBDqivhlgJq6Jz0j1TRyiABIYvPUMIKxV5EBTFp4MZ5gJHF
WZrmDkh6E8R4R64p+ZaSnwM0i98NIqO/Wv4WDSq+o3ubucMpyPsS6Q8TD1A2Jw8VM7KCL3sq27js
a5scMoYMbF7ubdfX17F9I0bboXcrTmAVNCVkUQG7GXWOqcBUbRbBbHB9fjO+Zp4mmt5NeQzFPusx
6kDYXbxQoL1mj1rhnHmxck7R4GvYm99I2cqFKv78Vpw+j0cjNXZCZ6XpaUn5DqUZBc4fcoD10w9V
5fQvR8zP/hT+v4gd0pIXX9b9s3qVWzH7HYQRWEY5bkoPlvz89GaGFNNt0ns/+a0jc4edXJnilFJC
6Bz932D6DvSHgmaqK2EQWrVmXBgV7miAfmQyZaculQsD2Lht8/qVzhYUEGUbZw/FhQe7A53k8TAg
c9slB8nsPitQu7ivLbMcNfu5PLyDuOK7a6IsCulU8Wz3tg+HRTY8sjmwd4lK705hXvpsn0Ey/dSI
o8qRbEbTL1OQFb+/S/PHamQSSbUJtk/zS2F/XvP58Pe+e1uaHIUDvkq6Q+LlFc+o9p3ED3I+cwqf
8WXl3v+zbV10GWE9cP6268sg9v8IXaUYEH4p2jpq5dMLJGq2V58TkgpR/gqdTh6sRrhOxu9aRcf9
NA3oHmMDN8WPXW2cLmI4BW+neNnXHJDoKnNfQOrwKj+ihuqWFPsKikIvZY28Hs7jFFDkeyXpbOfq
y0mHXmQrvrGJswSIFu5891rsZFv0DG4ugNrIBOAPDgWtg1fVa6n8UiT9NPeQubVJI+RK/ehQMrwy
n+BreXJjdIGrbXpvcbUpFL/FblLDvAqY08YCry/ZnZpyRj5SzoaFYjipX+b3CtxO1yFHnySC7dnO
H2EBMSIkFqlXcQNRXk1IwK2kC7mzsa+ZCVOQLwlRGN3TK+bC2A25n9JH2uKjuHShh6de3rSUdMgy
akeVmDnU+J+nUSNvKjcat4vO57xpKTLKvCgSRMvUPsaLwkpx1igg8RF1+DsCGYbc4ywrsI6aSIdc
Ur2ZdO/TxjM0b/5sSCiJQLpoqkj7obDc9uXZ5zWeYtZZSulku2KFFjaMJqTG2+XVvH8zu7qeXJ0N
+cStrJF1q6hfR5N/bN+okgJSkeOzo5CMMdauvPezGuiHQD83CiGgq3ZlT8jSMYjzNVxLC2XXsaWn
9lJNbs3K+rpM+9L8To7mC9wIDOJFBt0Qzwkp2RJhjaAOwiQjKl33nrSxOKiKtTgXN8rCtNBSED6n
61DqNBwqpqtCvpu4pydteV5Y8U0sj4nFgYiYwJRYtz7IY3UbAyc2xkLT6Qscxhqa2s1BR9s5aIEC
3eJYzXc8GyYFYrtKFbtOezlWfsLSCjUFc/g5/TfA6gg2+EC36wUX+BkqdVYMX9mJHlGNKfcFRUlj
Kxohr/kOpyZGafsXaDaYZBOBdlvZY9i3Me/nHW4jAhxVtfyx3YOXDS5oy/3w6muJgPYxckvaONp6
Cepg9fjRF4UgqI2fmvzlDvuKDn9dZJlR9OJEjV4sUCHL4FobbezlL3f5OAKcX01zm1/zl2L4iyZ+
5UsqY65sR/kjCXG2/BYoKdQTuEAgDoyG0ka+O/m7UtOrN7PJdKbs1sdSMQsG8oaqcgpK9Mhjuls9
kG57GARCTYbT4YxnTjDD1/T8boi9D7yLb9Y8e4pZ8b98gZw/aZYrTcw/7yqLPnHT3vFvSjPKQomE
re+wkJL/hK+2yzxYsP2G0PL40R+P6dKp9oDiMIhV63XR96hMHGDjsx+R49zZPnPLus7Ximfo6wvz
8jo7f/nz5L/MywKhX8MnHVkdOhstNtcqQoEuFKsU5CYyVPlU5CmtHwq34VO6SYf3cZZLDWTlixjc
UHaoTURfLsvCEKHSGAec5ftgyt+mw4vhYDY/61++b6tj9oAtOL/7tpoMJnOrJZ08NPyVRyfDt6pE
eKpT20Ddfi6aO0h793xY1IglFgstmTFvFjsl2L5NgZkUBLUcAKLFVlYhDqdORq9KhoV7PnzTv7mo
UlIeuEsLKfCSApnjuvw2k0JuQq8cTBWd0bJIuY6sC3Qd6ujaYtdnXeaAnNigWVCiQSFVwhF1spT+
5OpYDMfhgJqnTYl0p5T7AJXP6aWHb6w43sahu1VLqB/Sf3Xq1IH6v/wjEg96g0hvL1utxrWvKj68
fJgvWE+s0bL7KqqWyjP/Mimi5dvqUNSku9KlLzOSTCeFTL8g0a8hdHj9bi7oDy+Z2qb1O5nOPnsQ
atLKk+KYtdZm/vkdRu74F/Iq1NrYht+ht3vHJaRz30iClOeq0k+TxyJ5QxuFdWpBlOY4uBj2J3uM
0S6bNSyb1Ww297NUsyZRUAqHaiy4Z7om4f64OJXcW5uMDUKCWI4+ydA+IaI+Dj/SZODUqJb9xC3b
M6BEgr6QlRZvrL5B5LOLUt74m3JpDIDq6VB1GtYVdE+KCDMe3+w5+KR6MCY5wlWgYud8MD7fgXwZ
pfolX6BYd8xOV+Lp9kNiOXuRmQdxhpq+LMQv0oRZ5NLzyhe1OH3Nkeq7hHSDv0Rjb8eMmg+ubi7O
52qBFPIWvv6Mbj74u3gEhxo0xmTy2lISCjqY3rWzwvEXgp0lS52Os96loqDbAbZQxgUMo8KP0bhg
xb/25lYS+rfSKKT7acVwnOA2LxlwhvE9zS9KGxMQWwXS2lILkyILqUxbs0qKHMTOVfOGbykVJWnY
ee5kWdJqyAJa35pdPK6nD4JbY/6wL6KzyQtH7MMbvooghbTf6qDUEH7iCC5F2VhZcT5B/OzH6vu3
Pc6lsjppXl1PH7izoXel8kXbhBLSLDgznExurv+/vW9vaitJ8v1bE8F3KPtGuyVbYITdnh5juwOD
sLXNa4Xc7d65vYRAAp+1kBhJGLjr3s9+85eZ9ThH5xwVCM9u3NvEuAekemVVVla+s3O0u3H4822x
0orqabw0bOyZsE3K8/bX19dWHTeLkeLW9SlUW8PjwGKk8Kv4XgF11H7QPbOoOdPoGm+D87LnaTv7
W/s2GLLaqKll61KkNOUVeNnYdu5S+fWTWANv+tOfQCKE47r6lOgN4dvHzMnZCMsfZYdhi2mFuXKJ
ep50b1RUsTb4K5D8SwScpGx8kGRaT/ct66SRvMMUW2smF11WTpjm+UUyxquDMVhaIXmEtW5wkmUS
pS7mRRalXMWL3FR3h6zj9suwB92lECFFggqQUQSiGJwsIIwyMsjuNOUezarBLrG1V90bG2tO+zok
5vMmJIOD3lyO/TiORTiOYREK+L9Tay3EvnnkYUxZjG97ZP7rzowbX++iCx6jLUqriejrSa7Ab6PK
rGCWWFuD04A5vRc8+Ai1wfJcDuGM0A+sonY06/HtvSmIp9KLpN7n7t4b8QyyJgEwVBMWFSafdFbh
EKaqTDMvEA7nQjE225s2nwRExJ54Yne1w+j0lCPgrB8CDyi+N4yNx+KR0lDHm6kqlOnHq/y8xQsy
0wUBTA32wXRcJUjAwXYN9TMwE6I9w+kgA5/31tDFd1nJnbu6uof0mTYWYOxow8vzY5yAwP8jw2BJ
Tj2gfgMiLekRuCmCUSR6DoPxLtjeftEppS39ive+Z1igo0f2S0I8suq9oa69GI++JD2Rd9Lx+itW
M3if2k60gkEexA8KCrpI6yHHArVnpeIN8OIvTDv1e8CtBENWHsMz3bEzEIi61jXjdJBcXFjXitG4
Jxuv28qEITUtrZ02afoMwdwIH6yb53WzVjcv6sCxH+rmWd381fyRYX7ShDvYlxTxpg0cy/HR9ZAV
ws5MNBdP9OQlHeN/QD/StcI43TTWDmV2oo5lTehRHZ3OfEe7qhPaHSE4eL+xM9gQOir6aHWd/u+V
nJLB70+e1E3Qxf5KHFz/emr0sNhtkcgOJ6qQaQAYvYVXGsDRFW8/aAVZl8dwsFbAPHDDs2KgwpLB
ug7BghmbsLx44W+wpQrLgWsa2qEzpJK+s3jSTHYpdFWY7qQXUTWPPWy980RW9Aivga4LcmcyvOx7
+Ni8bgkAbqXgkUehit0T7Jyq7mcmISTi12T1+tlpau/gGWagY70xk6uuYuuIVar2zlvGhOUiYmJU
FzFzRyz22vU8+uvvv5uvrxmuSqXaePXKtqjaJm/ePKtRM8WaP5Y84+somnX3HND97vc8ubPxyfnv
6zOLiTNY9yMw7skTi1Ty8s+A8nso124iSICe1wb9kcjD/UfIPcNbqDexD8qzNfHgYD3VKVsT2ElS
IiDqeYlJ6Ak4Eb40YN9mTDFmItSN3ogzusYCAO0XLFUnfcUGviT9MWJI1oM/k6kSJxqRbsngZjg6
RyINbI9L0cUDSG4JR5c4URE6YAev+73jH398trYaDMaWK7ocF+O+9zgVmzSRksb3WULHA1LHI+mI
UU/1JzwxhUHOzf7xSmH3n/iDTBPwE0XyExrgcXXy5AmfWjA24bUbmn4nvLC/+yEr4TKr7o83bxq1
fxesrlb9x/9+Unu0er3aqP2E7Xq5KjPSCt68eW3YPZsRHP8kksQPv17OrN3eDO2M9vn82sZ02j+/
mOohwU/DWRZE1WqN8US2cM+WfWihtayCXbJRhpb/yXLw1iafY5JP3ChJEK7oWYiNwdloTI/V+Uv3
0QhEFMO7CEKrMdXIMHh3Xg4GuhrwVELPBRiWsZTtOB2MRuOVdDaEYV/MSQhbrzsFPF3gztsPh7+V
LsFPOu6LWko5JdkNjQjTPdWBkIiMHSZA3nCwILzUjYifzmUq1b392stZxQyLS1ZH5PdVlOuwRiLm
GLNzBCbPVv2teVh7eahhmjJHhtQs7u8QWo3ubDO6heaITbN0w5QmzHauVIjbPeie9Se2ObWG1+4R
Uf3gI+zC5SRkq545nVLOluQqmPiBh37HoYYSEdh33rcOzeF76CTNXvOXZtu83zg4aO6t6EPK3WgN
k5Xp9VH3mJZOI7ALHREuJhwa3I5Fmbfdntkcd/8PzPDMlXjkUv4dKtQVrJIJUGqlFaU9QpBAi1Jr
JjpnI3N1W+mTZuf90b/tNPeISNKXy2/oC+Jr3K8vXQOlufw20H8eP2bZDLpV9Tv/1A/kjwscjNoF
0t+s/fBCnk0Z5Htu+X3dnBNnROIWbbQEBDiHLLEu6QUm7mtVB38pbNXjYDWagYTQZGR9ZcHNMj9V
VxVzX1wrE2SHOGUJq3sylSFAHo9pUhJre3IRre55dH5Bd+k4gXliJZj04PNUZmDKKtSW7/qEI/bt
a/7khalyC5+JTdBSRgGm0vq0MeY9mQ4ehMCRUDrq9WQqpkWI7hVfBvC0khnHZ/QTbScvFDhoLwod
tzHVqs7zSB7nfo0YnxeMPq4dHjV6MjkUFOIbpDc6N3cXfEMSWfQqhFi8DZXeiA4/ObOnyBi/Ymav
F18iRPq5MBkvVJuz0YgjLekrcNwrK5Jd0lrviUdfMWEcOUu+IPvYKES4s5ZGjf96ISHefcaEfCeq
uMzr7qIGd2Xvw86OXR8PSvfcer8yMtELSuMDOSUnzyeOtJfnQ+ciCpqcHkFRCE/1S/H0C2/qqr2p
NIl6wF112TPdb4M1pBBll2Gx0kz4OpOSpYDDlkwwjgHA4koNT1n7z8bOzv6m+WrsUZeYgpggmApx
IpLuoIvr+57WR1+tyDfsIdFVyt09Z9kQZ0Xkmo409VR60BmQlk1xsGIft5SGpeXcK0IuBFfIOWWM
xNUTKW9okJAdqfA/zO2TbchDq+G9uYmI+HzoQvjYrhEPM5FHH+ioO42cmj5bg0pa2+1mUzPjeO2K
Me9HVyBxdR4qxIQWG8uyHJelNcj82VWfOf8Zq4wnPBT0ul3YidjzhlNc0JZ2r/AFC9RYlwOFczs4
NZxQD/um0pXIJvTB4ZOYyfdfCBo1SobHgcKTHlyPKPKQastHUBUzmsGe4dhyaIxPkM6BTuGsn2GD
5FapXBd2r+fPyLkmvTrgD3xiKn/oU1o1y8vGgSdvPb4Xed5/4d760SdO9FEPE3NYcVXC9ezRS3pd
WS7uWnNv4+1OEyutZsBedwL7Jk5ByIjsEORzYC8r5jnP038goB4HBru0jA4ZkSji8PIzvjjuT6/6
6hXLPa768lbwEfeZQ3T9+JrgNeGY9izLeeyaxh/tg2ru4dZkDw3/0ImEtj27YwH29jQKUJ4LPvEs
oyNgQ7uqbeV554Ql3hHFn4KbOqS7jBC6Fzuj0WdiCZLP3LEHTeSQ0MZAqKc701PjsNu7PLxkz/DW
YclJM/YxxYSXC/HtD0LKF7x+IHTKQRY6ctu3pPCRCWDNtwYWO4nPFzWtJ6BVjmisTdozHTbElAkx
R/4zle1kPAFpUgKaFsDS8iNSzYY+KXv7HbCY6isvAtxYvYTN926g77nvHh4U52Jsd1o4UxdRx3fZ
vpvsIVg5YDqJL5mpUz3kxHTVMzHIBkyin7RUJovFmLSDfNB46/L8IlzLdCTTB02EKPC2pHg+9aCo
Ml+ok+koNdko6jMZ1WecXmBaFXWfbH5nxjQngiQPkuNy4LFeHxPQagniMMjyoNFxFc5rjY4aCclb
xy99GM4wFTk2EFfvGrxQIppGSKbY1grRB5nmaDhaX8pJb1QRzjDFKaKhippFsqo157mJKpXHRK5U
JZYVSvPgzpdKR6pSz/O+FHKM9erzpVnSmOS2hubjbqsjigQwAg79+PDzmHShJZZbvZP4WCGQRQZd
fgNsWLcca+tU81FJhqqWOQJOHfm77FjCyWCUdiyy9ml3bjOv1EZgCeZN8U0f4cvtjdZOcyt85OGs
J3YAkRvebmyZzfetgwdWJS+Szs/N9p4GAvGm7s68Y3Idglcss6cpSeQIjGOENDJPpNAjkp0NjCey
gWrv4Ks7o9KDTsw++sJiub0K+KuDvYyBX9hIpfjHxNIOOWJZrZA6sR2UpIuDTpud11p7m6HfGj72
A+OlDG+G6bi4MvYQ0WFpEsXF767tNrtdtiK1jJgTu+WEVhtAw3h1YK8cb2smpuvy1Anq+Drwo4Qd
LvOKa8MqFADAVmGOspK+0HRQbXZl1iGUkeIHpCpUfCTmPMJV7Ka6K/ikrLLBgyrJ+F7vUDOvXpnG
i3CjtzY6G26nNZeiHs1qUbN46NLajLoFMkAqXd2TF2Kz2t6uF8w50/zNG/NjCSS5R6F8CQgOfWMg
7h1Bo/D5SBhIuDyLC6jrAisGUjswV6LnMZTO56MLzgVx49S63AEvM+BeEV/I/gWzRWoP54NdkWS8
9CrAsb8O3gHepS5I7PmPL6izRDZAwczcDadpZR2HaEKSXr8rTAKYAh+ke0GsfncAUsUqru5UJVo4
Vsi6uwP40cO5AIleRTTosjWUicxPSyLsFeDUZFCd2fO63AWLBW/eWBWCKEu9jmnNGO+v/bhaZYx+
XKviNXhiQm3Utvxs1mo1hxJ2ugyuTq5mV2R0SXZIxpeGRw3os0LIBFEO3alb9qqe4iNJAFuxuiMG
za+4UTOvUYXBWxtLr9AfkjzXtj1mavJ3HW25YX4v7GndrK7X8kavsaYOjCd4QTXqbu7vddr7O+bt
b51m+CL0PUcXGB2cTiiUU6skvnQ+suzy1cjvnH9RJTpH/0OLhTXchnaKkPbzFP/6ofkh5bKc41yc
EhEPAy14QPGznEqa3hc+ocXPrny5/IZ53SPxqnht/iM5PU36EwfvVT9QVqmPcfjKFb3Q3N890iqR
zQ3Ejv0hSvEV/5jH5RQ5M/ZC5ZOpDYotwAvAZ/qBKPa1kuYkGbudLpEFJ5h9XQyEZXQmBX0bdaMi
KDghUaRz4FNe4zWiiYMrOFk6pSU7SdaNRgrwQOqLXzDGK5tgl2/aG6MRnIlKqML7OALqdsyY/csp
bYfswapZXn4T8p6yf/xdavy6y4SAYeafUPSPT3ckecf9keY7Zqvsw8q8df0l2Bc+958yUgKx5quZ
m5byNcJ03sfosNk50lxg+7/uNdvG4zRuBKNI1wa9nvjsAI5q+nnfEBlrnJ7yk2AP9dxG9vcQxu/a
Mu1jmsmEd9U8eB3AVTMYwo6x3Nz72NpnYilrkjeyL5FGU3WCsCjA62J/AXUe4SXYfO/J7+xFIhOI
yjK1wkxjvAKrtXAxq+E6rFuR3B+LQLwCv/b9reYv64GjwHwkifxJkYUg99TdiEPdOWFNwyhrHeyS
C1jl3ak9vKLf6qLcIrVWmVu07614r4dRFL4+f3kxP6wswfQak770lzw/SwTCdm3+Cs1JAeW1izpy
PrKBkYCHSWtrYDlAIuMeHSttjx0ez5l+lCjLG0bi1+/x1HJpW248viNqFZuLix4JvlkZdyMkyemX
0TIdPuUy6ZNs95C75rDTqtZU/+DjM5MwEQdcu5Yk2tSnEAGvLYkfiOXaafmM0YlmxIOsTackDiDS
XbORwKKUnFwOpmLbmYb8GBuLL7E4PhVHSifTpKowCNi0J0yXjgi+o9Gw6gDEVI/Nr5JXW1/wnuSQ
5fdwnJyd0SJo2U5D7fMZISmJDHDsFRqchm1y3uWCIpdDTuQtikqbwkPiKRDhEVrjZCC2M/SEDFQY
GHlYMnbINStsKp/Ki5O3JNie/b2d30I1RZElKBOKoMLUhuUvfmisiSuCB4VYfcS0mbQ6GIY8mF6W
WJaSKNWJ+MChTU5u9iU1ns3YUxvzYupkjl+9gUncKb8EawrdgiaS2dylQ7ITWwuXvTsqo7D6EQqN
0C0m+KDUyOOew6B91orHz6BY3FibdjbKrlmUaLqu5WWct5NOHNelJQRt1RHND890yiLxqYMN3OVE
4whBKOni4DqM+1xrhrFSX9ouMRH0BLNh1YnPXEShJd3Zkm/dKGBlg+x3MIDShrEB+bc45sdp4GF0
o1VKd/RATRvBb0C01dzZ+M28b7abD6TJPlbBcdbnXUIuzexplSfn7Icr9XDCjJOp28R+deKVrM+w
khrv9yZFW3Iw5gr5mDCEuMQJfYH5DEQ/s3O8r5hC/7bMy4qMEDrYnSbXrvdjJkmD/vnE2ZBz4oE1
SaYY79Mhl13OJh7c79L4IokgCxKepscJ6XkXCh/EVVlSjIvNlKnFv2raUmt5Oxkk1fSCFY0EY4hK
Xw57KU4uoMWnp1Uh0cpKhLll5j+TMT9LaWOe51Ezz6gyFGnjHSLTROnVD/N6aS9JrCvRbOkkH2KF
azO4E75Po1AqyzPwVRCzp/MAGTmAhXWeRHZB9fUFAFavXj97xkNU6CkQvyt7A2RlzvOSi2VaBwo6
VmXtZcJnbsIW5xs4G9pMuUzPW1vWJhdmv7WDWTDmn0DEDw0EBLmXVIrmPQhfizOWSCpX47yy5Y2c
diefg3q2I1dU0YLvGHUuRssUzLb0udDOb8yX7hCR+IgdQL62hCvX8vstDx9n2prtyRdjqkUs/JWc
ODoz2wWryspntlXIhNrP8PYiVuwGY3zhrMWs2pVvXWJLK50EEDPqUL/J5XGYKA/dnEnyXXvjraDb
+B9uD92HwBCpFTX/wOb8yAsRuOgG7HBslruARzZJ3TFjRIu+dDlPuQ7v+GUt1njEu09/vzZpfhrM
9nF3+JlpntGfoB7lYzvAhEscWtLok7UI68GVOvpSHsMlO1q33zgJng565luDnEAAg6sbpL5++tgV
+rDM8KytVxq6mhv2Ic6XC3ifU1LBu3H3ODhptpJxaOqIHXFYFzHlZN0Io0F3Tu0gxSMnK17f8UCj
f49koKoNYOPo7f2j5sdOE6yqNwjWjFMGwCXdrSjtG5Emn0ovZVacG3NvYbhpSF29cr7KbUXjvrpa
g1oF46xCkz2jkpBldEArj0dfkGz23Xsi1QhLYTFTVQDqf+Oc1VyN69PLMYs7U2SQBFul7JFVl1+H
j/vMeu8MlUmBRW2Y/ZWrQQN6+CoVYlFHUOVZx/HAesq+Xv3vIdEIyWO4pvRQjoaAmfDD57eyumDx
uxpxciI26X2iLbCMGb4MnfomRJVO7ItG6w9zkvAHDWVs2deCSx/yW+vfQKvTcj2dMj8UrBq6nTl3
L2d/D5sZo7l+R1taNfmDvHljnkkMWnNVI954y62J1d0809rf2Npqm++uXdKQ8y72IFUx21S/u66t
PMQIlYcHtoJhOkeos6vb2xWzMj5yd7jFu9hLem5psMzB8w7TS40qjQ5EQlyve5G0IvSOWN//26Gb
qiz1mlsC6lcEbnt03k9JRI65UZ4cFxUJxliMsDh2zODJ7+wSx4Ue1bfdzqNigVoObRd7WbPo9Iz3
cYbImxlcajd/yaDSA+zVUdKb/J3+yBmBjuu5hjNuG/O7xyTW2ojDdcjTJVI5AZfRce65WEcY99J8
GLq+vdk9fqkIR03rUjUKUbNcID1w47DoNrt4wS537HHn3tXMN+JHwS6M3cnk8jyrhUgmlhu/vr7W
825N9ayR6n182esPp95A3DXQUKsvxu7Gpi+7Kp1ZPprIDI5Z0zacd9WGkI4cBdc3Ts8yw088ecIW
o1p4AN9NHtYt3+Hf2VOpYaGja3GPpD/oKQuRNe0oPtn+qsh5p0bHADQmT0w1caYTwqRl8zeJE8lD
Y5uqYSaQ9AVHLr+W8pqCfsy86DSyEPvXDNKDvq0y2iOmVLGCYYLtEY3+juFNA7HgdhA4N+Q3DFvJ
+5bCH63k59RQQc1EPauiBBp5rNYMMLutwINK53htcrs+Mmzdr9GjvsoRn7b949dlBSD9sVbMnjj9
2yrHrv4i+0ATBxKk4LBPKtPF8VRyPVTo3HsklnfhZMElIjgAV/KmY0Qbwa16m7pVx9JdG+LLhMtz
Vpjf+6XZ/k2DZJnXc8ndnWLjfuhimq2mtrcjkZ60ZgZKk04f4W597dKqbk7NDDUIi3mifFrxJPWW
VI2jN3xuSyHR0KG4hJ7QLrD3aCqFHhhzzV3Zc+mJnV60dSo8M4lnzP767BzWFAWVqLx5x1Ci9djB
hvUcMsKVpalIMZywsFwxK/Ido9OxFmu1zIlapdU+oj2lHPjlUJaP0sL0guooXQ6/6I5ZO5SoAi3c
B/EpgskUBFh6KXhQXvWZZiPjDDogHap6F2hW1MeHzc7hYwfDKMiBzaEoNM5xX+BkTarN4Ggbaio0
5OWHdtO+qZoHta4ZN+1APlelzPDJVeq0+ViGo+EyHSDduTGy2yFFFAfJM5/K1wkj6XK1OEkK8Y4E
M4+kaDn8qUdS49Kzg5Nwlw7ZzszugHRn5RwFaZ12iB/QC9GJ2APnYu04sEmACdVJ7ZNoKLh6LtT/
PhxGh31APw5NnIjnEfEVngmXxqJCd687sE+E/EG3hiuWebU8f7y87MJe3GCvMxYxlfS5d2ZeUbYH
8S24d58TDSLh40phml7kvCvmw9cTm2eTFxO4N4UBfpuWkkDnqzfjBpIwHcaK+TBh/clr4lJKAlWj
iUl2RWveV3c7udbMpVy316g9Ditjt3TBVkKQtcCogL//xqsyj4XLce3FJqARY7RBK9KKty04ob/N
Urq0Qksr7ZzCb3boAt/kXV5xLFS4o99NqkToX37Xq4Ef/O5/PbvGOulvBF0dtv6tSb8em719xF7h
06yrK/5KU/88/pRfDCtv1x0mcW+rPhL247yrlji5KwcMHkBzCSWUI7FXwgID3ueleejZqoCr+kH8
KlLYtLaydv3SenE5rif5XdAy1Sxw93INf/hdnwg5i4y606oInRIwUNH0rP8/cAq+YYpWwefm8zlb
P6uaEyercarVzbvtgyN4gjd3BLHLRk7Lg3SucmmzWO+u4lOfsjTUdVpHYBhnNSeyQKVZfdz0YTqf
maV7ZnxbmfGACbep9zPeHUJfnbZW8trrlvKnSFF0eZF2DnI6Ndw7NIWU6XbC6slA7Bw6mkfigjS1
rgurKS8/HR7jYLtlrCDCDEqX8G5dDm2KMjA+WAZdoCpNRN1e041zVCo9h65Fh+eTMYYdB4Mjtp+H
WON89Y3JnK0uT0gHd0EBL1Ym8I8Qf3y2bhtMpqOLbANO1ehaQHQTZ8Ujdo03yKhQkN7AdZpe2xJn
hIHSXP92TWizpNaWa5GttrVuPYYr7zd+aQpHj3w6bu0z1a6wND7c2a/Wsy7cr9+YQ1dBZPOTL7nM
rxo+aG3Vlde7nIgplijSaPDF+mXv93rLQcHlBOm5v7wFdjtpZD2lUr4fdj4u5AjuqQIEWs/OASZf
efywOUHA1yaXtMulC7zQlv6iyPeSP+eExqqTNvlKaYWYR3CWBEbYOxS/EYdsPB3WJ5stFhipsZTx
WBz3z4lHkXrI/AEYVGWj7G0+KPIBDkIyZhf6DNvHhS1e24ZPTeOFAKqT+q++k6+WcrQCMogkNQsT
l51cqmpCu9Df0gm/cPYh/BLkHuLd6ZKAqt0qXYNURuwS/8Qye8c5nzmytrp2jX/EB/A4ARPn2tgI
lj/yQHGAP11L58zKLi1nZTkLK1/XH8ER6qrsVQ/yWfrbr6Gqj83+RV9ue+ZdPx4RzUMLbnUoJkFf
HzEleFLLOr1ZJ4brzT1Wg2wmOU5ZocsFk94kpYUS5Ot10DumYcJ3mk9X+U6rS7OJkbH0orIK4hsB
rtT6Kv0HPLc0P7cU11BFgEr7d+ckxO1d3qGU37sGlYj/MDWkX45ae5tHiMXY3P+w11lPU36OZdDi
Cpa/aVsyt4viiktCDsPczLS3yOaqSZzXtcU43aKd0+LiJNXiYDNo4Vbj1pEtRT+p6Tgo0CKl141a
Ve2nWn49+zGXYM9+qGXYjeYUsx9rKfaZj7nSOj5dTY+S37xb0FzLs2ebn3KJ9uwKtUy7fixY5i+b
0yIrruZJmvjMJhrvhRoeX+aSx0K5IacRShetDPnLJU7ysHFyMhr3NEDwLVIdjOuBj+fM+rzwUkmp
3+spjUd1UGOlgYR7TF3mL/jWwgxAG7JiTLM7QdZTdm5cKdQMxqiahQKXKprT0o9okc3vCPL70ayH
Tc3XnMasKlTLq1P0F6itLeUuKm7E55KtaGSvfL+0EFExrcjJWTDflyL/h703Nru3LkgMZkY8P0QI
Gvad8TZIezvojs/6dOqS/lacQszkM3FYdINXTjQTpGDiQt5EdytPzG/W0mxw+byY8qccjX3VD8Kx
2UaTqlUGFWuvf5LApEhNcZ+Ox6PPfVZldvg9caWZWOPCaVQfsmbqvP/Ql68+Ecc/wpxuT1+eiyC4
+teN9l5rT8OrXf4BgM42gbr5bvIToAjEtlRFxZ/MQwh7oBuD5GT60Lx8SPvESsYTlgjVT1HYJAKd
l/hQFIi97gUJH4U66RIy1u6f3J6QFYZ1i7RWEJDm33gXWBKkn6qW8ia13Oi4ewxLc25o1kqDzQDX
6e5RqsJfXawzrmJugNJXHH9rJAUUvWFiCDfIazQEInmPt8ORzYOp4bsAUc0LOpuGKGqzY9pZqPxO
T4UCWM+wYDH9LpwTuhMtthhkJ8IYLJpzk2m2GELoUGiMDavgGwElP0RbXpld/vwtjfjJoxZuSdkK
x8Dco4T4YxsO5Cods/k0zfpmy4FI3kbqDkRMvFda5b5LgbDTunNYl/fxRJUeU/6IW6D2hC6lEugy
nj7W889zU5MboD5v4Uca57Qu4kiGkrLLhz9nvpf9vLwZS07VmFEFFpI5KJhJqA2tS7LnOar0OlqL
/JXJ/QD/Fmj1dpLh5bUG5yYTTYBqfvqJ09wPRyhBzZa/EbyB+U4xj7iUsnA4OOeu3bUkmp70gqsw
J2GlW3clMyNYUsdLuqMy8xzClooCS1JnOzNMOgOFcLbdXuZSq6N+2tsKqGdmQieynuoF7u48whxH
9yWnDe66sAdWv2oSHrFhTFBVg99fSHNf7Op8/NTz9ZQIOXuEqCeDRIffXc/EVgNGeZFGzv7i9kd3
BcmFhEryjkRnEDOPjL294j6pHcJwEuGE7TWcXToXfmerXfasFJjs5ZFv9Xh42jCmpb35iwS6M6ys
yB75MtHVSc3axXN3k7+o8Lq0Uq+v3puXXkdYjJMvPpuLZgvILksD8u2yik+y89E02+39ts1oWJxK
jfnJaz8zZN6NohR83ICR1S2mIPdeGQguj0CY9u/yoie2mq7Lfl/ouVIJHoCZe8xKhWbgtcLDwxSN
jPOjwUAc3uwcPkNv8B0JZMEMTgubmhdpUp+78VmbfbHoDHa0KfvxdeUqS4zKgIn55PKCnY21hVfG
82RQfa6Wr9NmzLOLK2yI+oyTSbq91dPkHc2a3ewypDx6+2F7G3VugAHzcTMOFbNYVYiRQqgfvTb/
lemxnjknkiPkovM55SRc9R0yX3jNSBH+z+a8TG1YkFJqw+eS8kStNCeiLacFhtuTwRHnNFR/FmUC
Uh4B4ba45VlsBH3IT8YWyD2CMUEJr+CBszKyrCuc8iv8ibMk4WtI54LRU3lGYGBnIZ4dw+xZEQtu
M4IVZ8pKbbl7OiABSHxLUO5xpXCzC862/fFo/xc6xPB0PVaNr9OZv9NfnSano8z38egfTHxbeozi
U7PYKDvzYe/ww8HBfrvT3HppqCFGlNJzxXhYMM3uVjiJlYW9aHKH94eHvDW4+rJHwEstYwC+xTHZ
yYsXvfSXID+t5dzgKLTu+UArPTomlAUcZyEooMxLlsvE1SuMqLQMlilgDpMJJ6IuYxBFv5jitQvz
vM0uNuDzLev8dEYsYJ10SiRz7BXf4hwe614z7ziFg/JtZhk+DcLoObWilrYTahVoQzTGueqTgNV8
J/uMiF2bGWzJPEBdg3IdYZBfO82F66ct5KK26crh9D62aT3pS/bolhTaPIW6f8gaFlZFFFQkJ/b2
9ia2OAubmWNiMy5DJKd7xaci7E9TWgVt5BJ5Ls1qUAmKIs2peu0z6q7Zy5iad4ZVbX/cbm3vh/eB
Be90p0e+GXNNTLhALJ5yMiqE2GuOCnF5tlHzsPCp0ye667sYkju93i8dGmtGUOlPfdGvOIEluEkW
PG2kiSVM6TQ3eZkpRWnCyJdw4nG9KvJxae7IdnNji5gE/pUI9NcwoWQxnXmqsXRmejWSHIXMXevL
wI7J4eGrxla+hUYrfW7p/GzpnuWNZ5o/Qpja6l9PT9cNDCbMF4EZmY4ufCGwpcDuS0C/NIedjc4H
ktOfX5ud5t67znv8yogpa65nwAmxK8jS3T48YinxECFb/+nOlAa55CVIhpkuHfBV6jTcXdXcuFI5
hpFCMtw+Nj7Fq1Vd+LJroYzHSwoX5NyIVPz3TJIbwJY74JfXpvPQyuRBrSNoh8dB3dmx2AiYsk66
pxzHJdrvHoxkGAja8Gr+3gGMjR6nYMfgEivgAgOdKuQ0g2UCZXrEZaeKUfCxCFEQOrYkVLPt7dOO
NOUV3qHX1/pqOsdwLjFZzK2mGU1tbplM9lHDo8l//mFhxX/Ng1SWBzadgESIR4FLZilxFi50THvq
m0KdJn3Wn+Nz2Q3aSS7qaw5l4Bbnnn22huSFbtx0kT3k6oMNZvylX5UqReBqDN+ZBtfODHrqlalI
rmH2mKL/+mN8/UZ88fa3tpaRIdG0Dg8/NM1LjnPlLIrwglHzkM+ycppc991b6VzI4FRm3rKr8CHX
K0zF8cFny1jPNdzO0VjGmJxP9D1zjl11sAWvTYPHap1K+LHk50+GJ+M+wxYQRsUmriJI09HdIYC2
2xu7TQ6KUf/lll/I9xPnOYYW/X8gNSqdvo2joImOBwnJ5DdlE8otl9KooJ2atg+vnwtNDDrRRD5J
OVy1us5Bz5oVuzewklQqQEQ2LPK3mrpVOjIoFWKExV8Pf716HZCQ6t9wg7xTXc08emSqjfBD2uEa
kxS5YCnBINg7datnV1tOV310cTlVnEtf4yds1K9we81NGtWR+lSkl944312WRmQNBDPI7c61iS6h
3PSIV4fbodmwPcR5XfK6TCANBzBxm2iIHB3IywfrOSJmPHGU3/VMT4hdFQ/pd3J/JjXPOKRnQbLY
7MyPtKwj389//dA87LT2914as8MlGeTKdT5a+1wdj5SEiTG1Mc6oj3Zbv+63tybw7cdfkuJJ7YHI
Uzw6txG858m1eIWbDfu7xlMm5yhd6+O+J6jOedDa144XQakbi4TDvDS5xJJh27PQ+nS5KTU6l6Qa
4QBl0W7k4xx2QkamD6rZndRUupu1vM3nSGhbTFqxLvdIlUnyB1oNT7Q6AxBhzuyhWnQiGPJT9hbs
TkMe3aLMvYSYlWwyb+diKBp3QHHAw1pHyEwu77yZZVecL5o8IIQJ05H4QvWnn46Q3+SILfJVvkFW
C2Y1TuPrTBp3++7KVKrcCbMBQ3UGOc34aLsipRHvZZZj2th5t0dsHLEOJq1RAsOTViml+1apc2d/
//D9fht6N/lrZ3/vnanNMF80nmxS2YA0wtuNrc32Zi3dE9Uww27CZVg1RybgNEyLRmPSMSMlhizo
UjNJSdLjIE0aYvNRG2/pL2Bl4O4MKUO2lf6H/Nn1vCqWJIMkPVc4bFbioNnbzZ3mxmGzNHPbUlbB
ABXDff04TcP02on9Np2TEcMXmHTnIiNQa/IeuB4wE8cWYeYVXMUU9Uxg80JQ28zXx8ReQbSye2DO
pZRtfqKnQzhbWOuqF6nobPhrG6/tPvViH4QdnY51tdze8VEcw/uF2Dukwk/Ucs0OJRITz+v+6aef
tPRJ1ioJQqZfsBYEX/U1de9Kpcr+i8PeT5z6T12W6lqFkBiioMTbaGBBgvDI8Z0yY9u6c7DzjcTF
0BfzTzbuJ0eZMr2eWwslKXc8vqu2hVljVe7xXrgPlZRK8RTO5jO9DhMNLs1qU6bXccqUtBOAIlDW
nBxUpsgUBClRuQQtWRL/67ZbgjLOxHWw+gQM8/nF9EZYZZeakPNqMsFIqW5QXqQjU3VUbQP65YjE
klr0BxJVDESehLeDtSmq/AtdBNz49VzAl9J+CyKMShGJ4DbU7M3LJXlhgY6vTuVSrFpxpzyz12k1
Sbqex0eztb/XVEXGS9ZkZDXKbmCdKGWfC58T3nm/DNr5w6Od/cPO5gYexVQ3ovzjpD+e332js7m/
4+rTh9I4Mx38OopADuWDM+ya0QkXBWaDF9cUgDms0AEmtbYrEr1GV+n3NccdGy9fm32u8SHNhMkx
9xI/rNYGnAdV4wWAIpiY1UgFXeS2P/ywudk8PMyLAT50djKLQvxq9DKmyowW/g+LoMu2EoF9tBgB
i+z9gphp5IK/v/AIX/l3qV1Qz2ng7sXnRN//EOnn1sJEycaDnzul7z9Gh/VwAJO5jp5XqCjHYsw5
UGWELX5rNP2nMK9mT5TA7f6ZcjrgcqTMgyS2cLZ8GuCAWnrFBALl6wb1O80Pq9LmliyXrEwoT0h7
84lPDgs031gw++PYHY5zdMwGUyvoIzX5FWKAfEZWH/0jCoiEKwdzR3AiYA+n3cFn66VJILGLGlHD
AbIcmU1B3uMb7WK+T07FURdM/0eDSrLfL+KoGbziiUYdMXzlNhHrKT+6yPgFq1Fsoj7B2WT++r7y
DHlP7Hyf/svhbb36nf9BcBaiRseony6n2MNqhhUJ7s8HcQCynJu6tUALKFJRXiDRVrMwkOj+Qgnw
w2hhOVhb9t0vM/B0Pu8GHHZQKh7oimAtiCN8Lr2FAgP4J0CqGTQSp57HuZG7RUjHZP6OnGEO+mWn
zWX29JweuafwXg7MEZHZSGNHUVJBHRCPsLgLLeykljNh5omkTzQ8L5nWubMW6WUDCZTP9BpehDYO
pfJ1Ej1x4VkEgkr5PJmcXI6Q6xkhZ1V+HTqbB1sfdg+YUp3Qd8kQVb6QBJ5HFZJkmUXWDJ7OzpRv
dZ0Ff44RllNVFMsNOac8O0XuOWffWU4GHTgaw3mUfTS2t48O2vu7rcNN49W18yd9ifC+g/buYZ6D
pWcgvCAQ8A+2a/CutQPuoeLcqonzg/e0TZ+tHr0zx5oE52NNscByZgtX2Pigma4Y92Hvy45hM2q6
7DzOqAqzXDA4j8Yi/Owy0rOqEEVgvNdKi91zoJM4HHB6ypFFZDgpz6AYlPDGpwyyZl/ORoHL4jtM
sS/paDquPJpo7jlbjzjIcT6VMtkuo4jz3pnBjo2dHTYSeuyION4N9Ck830j04kHy8MsZtn/VKs3Q
LOXuIV7HIeC66os2xlaP5+oSKyKZSaLlS+LuV0LtDZ6VT5LWqjsVh31J4yhdWfVi83Gkdg+sAFdd
rxmnclRPUh8UmcJYa0KjhrCWQjPeCtVlch4tVZdzoOXEWYfz2HV/Ho/Mf1XthQsPpxamV5w5IVrI
3n6n+dJoKMMkDOyEmoBd4Zkc82qFQaYv0ZkwjmUxuUCa552zZYqGQcxlDpfVgAWtlFofBSXcDlm4
FA/s9vo/OdmFSDyi6DWxVMzvzVe/M0Xi4/1vtGy17JnowFrfnyuhE3t3iNNiYR+Edeqlq3VEDWmC
vL3WBjwjdln7z2imjt4uvAGwwsb8Jmvzm0RM9NxYaTW0g1nOs5jnwvnbfPnrUucmGSl7nkjsVfDX
cMSF5C33rhW2Djbau0TG6uZhwnaL1MeI3cr5XEZyX90Ls7s76l2CIKdTzNvgzXthXXlLaHyE39Nc
VXAtXnsJxSwhT4bpcCldg47WwgN6h/3OZCHNRmbYIR6+NL+NLoPEiHiquEASTP/8bnMJw+GEpnlA
kwTCysno4kZVCS4lAJNuac0sH3/fyyZRYvQP8GTFsVfwHGLlafgtHTn7H43/kf2md97FN3L2rBVC
5rWt3Q1J48ScpXzJhubUoLR3mtQHv64TQD9LcPTaynOzyW/MxCynkuOwlV2OxLx2vqdHhPw0cvVR
MHxNkm8HCk9/lFjJN5DMNqEHuLwQPuhcMRfeDuejL1YKG5+z48A94C1z1ycyZQ7u4qkaOe5IzBiS
9QKyKmdfJiGbSMaA8Mb2r0lDm0/Li9+5Oyx4yFUsNXVWiDB1k22cSf6T6uDwLycV0JKLYHTNOXgY
R8u5sGa/WjcR2CRk1SkUhJYp01Gknbg/upacol6hlkrFJfU6M+9TLTHC8wct+QkEMtbB476d8/Q4
B5qfA3KFeUlcBK38Tg3qS+niDFixfImMZIJrPC61lURNSznqzNCVWhqm9fRP6EPjyKeMXLEtv77G
pPjS+groF4gWkW+WrKpUvnHPaaARrMpXtfUFNYP2h8+x3UcpBna4/qeepNXeIT9a1Cma7Bnq0RWf
lEjFM2dEDJ30tmRV0/r7o+EPV+93n919ydlaqeasJQkgzdTuc6edEsPfmXlbzevxt6NkiwVnA4R1
9+CboOg/ffMyaFq+cfO3S3FrBieDDdOJg4Ixwl+cjjQl6d9/N6+X/oIUYPRffG78z8F49CXp9dWo
HyYxPx5cjo+lz+QKWpegTzKUSEgS/U6nLMRqEtTUCNa7QxJNyFA21ZL+bIDro79HU64FtSvpoBrS
VhMt2Z+2S6l8iM/rSKj0mv7tHl9M8Af9vntxPNG+moxppu/2JUlSW/Rd/xp5ziTPsa4tPd+G+EFG
TNZNT6YdS2ayuZ/0B6lKdhI68m0t2MzslO6CZKxyP81rwuEhDb/bamm7ukTh4EOMxB+u2pPj3Fj2
55DLnmR2gTe9CjfsK9ZYsRcqDz+yq67JaDanll3KwXvzdjAiLmuHPj3unnyWZmoztT/bsJbSVXS2
Wm2lKa1sK/qTU92IIxxHdBECqd0YToYTCcpF9UjNR6PbD37ovH/uRkKqULjHQ01sk/OLZ5+0n46m
QXPTGU27g9IOg36va/zPPpfY5XyWza3lDVM9oxntHlHb48K2b031po+N1saILBr3v9jGLtNma8u6
5Xj6paVXqNfD+xI1D9nkpOHAYyl/qkkSUKXUi1jfgkCqvUsnr+J3UUU+pl+FQnI1o7oV95H4zXAR
iwt1t5dsKnJykijvaGoeD/rDi3RoUzaFijeq+G8e12ja5Tf96+m4ywnZbmGO8T3XmItwhL4wLuox
PYAYjXtqyEZFOUz767ivbB4kTLHRZYVeYAg8p9zjBi2u1jaq8tjYVtZbLUlNAgQEGGLrj/DmbO+3
N/d34LRXsQvKcFhOS1O3Zn35RXqKPifIE5Eevd1s7jZ3U8NXtVRF+EIGc2jRixpX5VBXyMdzaliE
C8guobPfmV3BvLkfpcpp3GEV6TVsvm8dtJu/FO1y9ZlfgqazLd/Wje2tDwc7H9NAwYgHTevBp5vG
jwQBvQOIdz3aopZbzQ6ScjW09nzJyIcHzeZW3MCHB1t23NVVGrlRPvTO3s/bG62duLG1cdyiiaxu
zA6byi9JyIQEkzuHHzeODt9vd9JHvPrXeeO/jR7/7e3Hp3d2/6DsCjY8fqhgzrdQf29+7BzRvmVR
RiV556udnZWGOHp72H4J2vIWzOYhGzmLcDS4JtRrPo5ieCITPHzHehqhsNN4NIiYQ0nN/DmaCgI4
kcOpROHOHR2B9+L+FjdJWwGxGWXi4WjHwrHZacscmzBnSFDOnLGDbCvzxyfaxsPvCnfT8kx6xEyW
MM7fqIP0Tj2li32b3TrYjNyt7Xd2t4JaJUUz5N6f+ZO83bC3g77Y6Lm8pXOmsEX85k/Q2miv8gyt
YS8hGQwiQ/w8Lmlo1ESNxSZqRE+0tthEa3ETvTuQs3nH5dcH1ik/YpJ3B7EXcsehWBn6hshF3eMu
o96S3d0PNDxXBSoafi24hd5XcP4UB3syRcqXMWIScSqcP/62HkCQKafNloan7LJ9gExJEdN5n/AI
kDoKksQ5xADTiaRbWzLyFsK6Isa13tURF0Kfp5ZzzZVH6ulud/I5YibNURKBUh294rvO6tthWao5
RBmiRtFcAe/pjb1R062VTLd2m+nWoqZ7VjLds9tM9yxquucl0z2/zXTPY95m+zh3h90zif1lhDnt
nhSStHCuVisOSUi6sM+zqBkiBo+SSDA4MuwoL9YdD26I9fklYnjOyxM3/ke9/1b/VTT6X4PRP0Zc
HwgdxH7NSsHUvse5ksbWH9eOy87kn274D/Sq8Bh7MfQfLcF7LjobxoibrbXVWHQyGiJ2rrXF54rg
AdBwY2tz0bk2Il5TtGs3dxeeq70bi4vb7xY+MIwRPdvCR4YxIvFjb2HEj3oS0RBZsxadDGPkzebD
ozGbCthLcPXgchU8LX35L3BITM6G8LS8HKrfX7+X0qv6Ya0vIw0Krz4EPUJjiifgC9uOGZB12+hA
QuFZBXgGPlhUq6y4dXp7eH2o/wicR1BI9QgVF6df+idVVrOqipWVqsZqUlmDOuNMgkFqbv5fudL8
iToZIDOJOt7YrZ3o3FKS/tEj1XnSoF+0bBiGToNWKVBe2tapUz78FZow3uyUCb0yW6Xkq5QpkR48
T5A4YqY1bOyp5twO+JN2IihSjkq/OsMpkwWImoahefB+Z3//VkBAfYE+0WAEHW4JiO0ZBUqgTI6E
RHpEw+Gac7unT8PAFSiAjmGKuiWEMmYcfK0dBDYWATjOAAjdD7ocUZ88EMdZEDMdFgOybYEMR40C
sx2ol1kqSiZsGnRXHYHhQ3HXs4ZbyH+Aw22NjZ5Ua69uUzhnZgf/M9iYULX6VWsD0Ypk3ZK2JdjL
op68pTNdLVQ5xSLcphbViijbNK85/yfsmXljGqsh6uXsGC8oF+/yNsm2/kbbg6jmvea7wquTs/4N
ah+9fG38jVbvLAz8WGneOBsNPKV3l5++Z2Yw4cRx3DJ3qWITqKL7q1dpi8R6fi8k6pVONHVOHwtx
QCRSrgBF1CJH7SosUDj7PErhLCPfYl/e3mFf3v7P2Bdv0bnLEopNPnIJ0naffJKeY/2ZlagLzD8l
O6Kmn7hnZI4FqGQa90BHTpNvBCqZIG0Aip6nxA5Uhka3hCbPFFQyfGAGip6i3BpUMplaguJ3bI5B
KOb2xW5boU0oO0mBPTVyniKzUMks1iQUPcccy1DJVM4qdJu5yoxDc+Zq3HauMvvQnLnWbjVXiYmo
ZB4xD93irs5aicrQrbNzu3uabyjKzrAWXFBvJIqepdBWVDKP2Imip4g1F5XM6E1F8YDNWozKQOrc
jrZljUYlQ/vMgbEXZZ7dqGQyVZDFI1mE6Sg7Xa7Z6DYzzrUexcy4dpsZ5xqQYmZ8dpsZ59qQYmZ8
fotHfY4ZqWw6MSHFv+t5lqSS8dWKFM/R5RuTSmawhqT4KfLsSdkJZm1JUeOnTEo8JutAIxXPKWtS
9HzOqHS3+aw9KXo+a1a623RqUbrFbGsLzRbPO4SmpbvNthH//KaMS3ebTe1K8XhpzUt3xEu1LN1m
vkWOztqW4jFlb5FrcJvHM2Vkutt01r6UP1+RlSllZgIJi7MzuZFRood6IWuzWFt4VPeZpHGyIQku
jhi+6PcVNaxxB7JL43SAu4tCyKv5/g1i3LKltL9JqZQg9MHatKibYhIauOiHx9QAH3AMgaAdv+k2
vQantLKNJ7ZuB+oCTHjXkEcDx33eP0fhZNZdjUbTI00MsyphEqNTk/6GkS/owwmX87q4L7I9+Ljy
+wRf1RxILZvfQGDCUiQVDe+GeZ1ZoGySNwnq9m01f7HfwLip3zykzX9oPz/vXg/6Q6PFi/gTiTJb
/eGHH9ywn5JBTyd1IK7LSsd9VE/mjIKI75cCJtjnAlA4b52EslQl/o3x6PuJfFgLAUzNlYHP/vrk
CStVd3HLj3HDk39c9meBdilK7gx4cE53BN3dWXtl3ZHOIPFA85iMb3SWiRleDgbh5mTWA8JQTRge
k5hXpmop8Q6Y5eZep/3bMhJUP3mSsHEBFzazRoXihIRp5Bkb8ZWRo8JSkj5TypPp35PfV9hYbkOj
Xoe0Qj9c920lagiUAHSFLz+fmVjyL8c2G8WFF0WDjmu+4+AC5WiCjp6kcNb5YADnLtDaIxl6WQM4
J9yLg/gk+NOfCaiKx4YcENU9QPrx+pGYQ18bGyXmOs8SsiOsJD26vZAIC33ov9KSCAo0YAzCVX0z
h8FKTIobKmI/f/5cDRBdiWS0e3T46y/NNv1KuPHtwOdJ8uHnCNrCDdDg2WLAZxvMBxh23CzEuYu2
PhF5q0b0aOGyHzmbpTSsFQOQbjgLx4sQjuMb3Ev1TcFfeAYsYOoxEQGZtswHTUNZI2DTlhHAactF
oGPbUQRs3C4fMo4XjoCL20VAxe0WgUmtvxFQact8uNQuHgGZtaDPh01bLgKd+ktEQKct86HTePUI
6LRlBHTaciHo2DMgBjjncJADG8fVx4DGDWMg44YLIWX0sW2UHVs3+ti60cfWLTq2QmK/EXtKGyWn
1I09pW7sKXULTqkQDg38jABEW+ZDotkVIkDRlhGwaMtbACOuZRGweDe4WVAklUIEJNIwAhBpuMjV
UUe4GMikZQFokv8hBjZpGQOctFwIOolaj4FOWhZAJzkpYqCTljHQSctb4KDEv0fAIg3zQZF0GRGQ
SMMIQKThbQhDc2sjAgo0KyAJ/V43hh5QsxhiQM0WwTF4TsWB87YQnOM4cI7jwDleBBzNcBABkbbM
B0qToUTApS0jQNOWkaiW4zeFJuIsFQGetswHb9w/OzqexNA7bRnDB0nLRQ6vLY5akdBRy2Lopiex
0FHLSOio5aLQNaPPrll2dv3os+tHn11/8bNrR59du+zsxtFnN44+u/HiZwdvuEjw0LQYvpPpOBZA
NI2EEE0XBXG3FQshtSwG8DyJhY9aRoJHLRdGz4N4/DwoRdCLeAy9iEfRi3vA0e130ThKTUtw9PQs
GkepaSyOUtNFQXwbxe5ry2IAj6PYfW0Z+/wtxu5jzfC3jAQPTYvhS7rj1UgA0TQSQjS9BxAb8SA2
SkFsxIPYiAexcQ8grsWDuFYK4lo8iGvxIK4tCuK7g9hrSC2LATy7iL2G1DISPGq5MB3t7MS/9Tul
b/0g/q0fxL/1g8Xf+ujHcLfsLTyPfgrPo1/C88UfwoO9WOioZTF0F8NY6KhlJHTUclHotqMv33bZ
5TuNvnyn0ZfvdPHLd9CJPrtO2dlNo89uGn1204Wh24oFbqsEtl4saL1YyHqLsy7Rsm2rTLZNomXb
JFq2TRaXbeGbHgkempYQzGk014KmsSRzujjXAmf4eBBLuBZaTCzXgqbxIC7MtcD7Ph7EZ6UgPosH
8Vk8iM/uAcTn8SA+LwXxeTyIz+NBfL4wiK1b6CnKFRW30FTcQlVxD7qK5i/RugpqWgziuP8lWldB
TSNBRNNFQeTIikgYuW0xkP3xSTSU3DYSTG67MJwfo/kZNC2B8jqao0HTWBivF+NpEEDuYw7nQWnj
UfKh5IwI03GMkdk2jYDSNl0UShfQHQMkoliKgYQTdiSQaBoJJJouCmRrK4bN0cCZYgCTXgyToy0j
waOWi0MXw+FooE4ZdDH8jbaMhm4h7gbQbfS+9MfTBIEh3YvucTJIpuJGHAPwxtZmMcDd3kkkwNQy
EmBquSjA7f75aHonaBHqVAzuuH8eCy+aRgKMpvdAaX1KARN7VREqVUJxT89iLyuaxlJcanq/0MZe
XQRqlUIbe3nRNB7aha+vC7F+Ki+NFmyJhLq1V/LeJMPY54ZaxhKs4eKPTRZiDSqPgRcBa8UAn9NA
kRCjaSTIaHpXmItC6LijlgN7CjCeTm4mT3v9L08RvEMNsAAb7UEzcHzA2BaG1C84boShwnQ29Imv
6v2VMtNQOVuWUm8ll3iSsloI+TgZjCb9+ymxWRAe58tifpMAuaVU4c2Z/U2dhNtfX8ZSfkmVrXQ1
LZ8+JciYru3vddr7O2Zjb0ubfmhvdFr7e3P3xf7wpEhf5pDJvDFrKBBzL0e91T++PDvjYKswFvJL
0r/ChyjIFcT2T/rjBGWrkintbb97/k1Ov3d5fgHR+kjmqKIm1mOesy51nOi61nzh4ESOUsv/Pnzb
6vyvl1IhOBu7hY6ZSC3b67veQxr8u4aYRzXMyX75v4e7W/vN+EFxWlgukQ7ziPMcoL/knrNjNmQ0
n2jOfrH6sHAJZsElLLyC1oIraC24god6DeUS3tMNADGfmK4v1eiKXOUjf+LzW3yDirGE8dlkwUEF
R1wFY0O63V9jV9MRbUeDHrKrrQfXo8It7ZvGc+F+jSUIhb/ko3rx/Hfb7WTwmQSVaz5iO9KQeBR8
6AahufHertvn7dkaF4Tsn1xOkatsNESS3qEB6k5Hpj8BcU0mn8zkZniSg0XP1jwO8Xp0EU+e/E6N
7D0yX+2vbt5DDkg+wSv9arXxBjAVdl8v/TZncH7sTyQTknnVWC0fPjVA+TJkeK3VpykjDU62PyFK
dz45NqfJeAKuECeHBw0nVVu9lrJX2d37IecCKqrQBWTehy9Z7Nr9tZwHBR/Bp+SUUy8O+9dTg6qO
Ey5/i695+W/evDaN4FanQaeF+gs45GxQ97cFNPD/0B3ojBNOt22AW8h50B2PLunXalBuspaLRwz/
06f5X8jgLdxXCdYn+jaVWF077BLutN5n6qVDuL6/JlySEQM0XthMmtntbrwou69+IdsJ8k+ecNFO
2ZCy1hyFzBkHLsfjvhaypa+Urpl0PWuUrtUytrbuNcbgzJJS0RZmIPBOqVq3z4LG7/rT1Hwg+w4X
v3QHHPeu9DIzu+YwCgbrIHHF6PQUsgGP5NIh2V20I3ESUotGX/mXzZ2fv+pL+dW+2W7kTd4/DPvi
uTm5ORn0885EZRnMNRuUvql1U6/MMtI34HRBv/GtVEi2a/tq9Omu50FaqVz2+oPuTfWHVVleavj3
CY0uqDNncHvbCOyYeRTJ0K/gFDyjkb5mbcknQncz6Q36LsM9I8pUEZO+pDtbl4h3+weupW7UVK8q
suGl4MlfemaHZBWTKbKljMbJGd8IRs+JTYI6g6MW4cMRTkYsfYW7q4+wpQlll5TxwLZ/9UrI0dJf
QmbN0gTcyizbph1p97nEYEDL8gUUx7nlMza1l5aVef3ddV3otP6GeehX4vjqumTheKRR3TIevNO5
IgMLC8FdQEvPNdraAm6Yyn1Kz79CIZDiKLVIwT+Rn3TCFGsnChnKJeX+8ljKugl5vDkMpvCU8xnM
HwoYzKX/d/lHRgfPQN77+H8ykH8ykHdlIMv4MMHbkecAUR0cpCB3X1evf6QnIeoB0k3lt+R/5q5m
GFZTtY9/8VYu/cm7RvGufzKu/78xrhG8YQ6T8t/FHN4fG0hEBHpFOohxH7kRJ9kn+j75PdaLA9b+
lA4FWzlrMnlsFs8p6HlHo8nfjruT/hE+wNeWYzxSD47g7zXbXc/L/nnK75Ujogft1l7n52fVh99N
XmYAquHEfca5gGKedIdMXIh/DPZXSuAM+yf0e3d8Y2mOZWmY8tg/LPOof6eIDysA7dklPSKzyWmi
+S0VVkOjFWhvRw455ZcDn4lWaINuz62HcOXvMEi4bfYAcF3s5gf3peJ20H7bcM3scE/DxHn0ACYQ
Z+g5IaHCb0BlSR/zqgXhjQiGqzVUXnOfvqJPT+kHn6ILMnxW7cbldWn4LsIZ8EmEUzW4TByzHOm5
/MfSU7um3mbavu8n/hLia9j7PF4EGEo/FkEb+rfPaGrrQvF/hWZjjQ+4h0chORs5mr0RYxG3mEVn
V/QuZYZSam8xcHpz0deZ/Ia9Fpm88UK2w+3HI/p4e3ubdolbbP/4fJVeG782BRxjEohArJ2NvR+f
bTZ+ZPfk1Nrp29fuW1OlX//W2Gw0Gq7ETM4FDfclu9q1H9fKV9vYpFcoarGrpYtdLV6X7re3n9+H
/N9NlNhPLvonuCo9lUjAQZ8nA5JhUSyKXodl85l2rj8wp+OEHiAkhPgWOgBa0NH5pHo5nCRnQ1oN
6O75RJ4Ci7TJ8CixThrVmt905SyX34ic8dp0kD/4w14LFWDaHw46rbc7LLRWJief+r3LQf8IUgdx
GtWGeULTmMfm/b+Zp6aBW2m33vHwJXMsMEP+gO0Pe7Tsd3YN95ZYuB+87UjvaU5S3kxdJGOlnT1P
sPfHN9z2coK0jvfPAOAqnSbX/V75+z/nHb8rexAqk4zmU/XEVPRCur6jk+7FxH2qPmRLswyAB6jw
/W8Cb81OQiwniuAdB5wyxr3dw5oqY8vdv772X+zs/bzVOuQtKs+9nTtm3Vi3uiVH1pE5leEzJ2nn
xqdPHTTZGn70bWobPfsU1vSzOfuA7unmFiLk+9dShdm+nEUNZJgu1ZwRgjp+gdpgnILHqkBpW3A7
4EPu5NTbbqarUpBaUiiuLG+mSvHlFIIKJxehiF2qgoJrVjoiCqNloUIZ/fLkRJiHmQfkXkiKW3/2
HQGJuZzAM2dDskhalKA+xAGzTJGhAzVwwZbkmE9Ejcb9f1ySSEfDEanqj6fdZKgka+WbvD9Yiy9/
+N9BlzCsvhlZMhUSJl4oyBKc93ZveLczt9I27fZSLZ1D9sw1Fs8Odnq0K0FOv36JzHMxHp0hCfVF
qdCjLCGX9GP/rUH3bEmcCDXD6FH3hPXozs4jqi0RZpT/FcUhOCriTXBraVKlBQ8y8hdOyfMFhHmj
2dM96l8nU/vALqVUVDJSn+XBgPsuei3sXZ541peE9v50Clgh7I3o07EoJmklkh/8joTE/3XY8TsM
Po6d4ThVvCxkBEX+xaCP8tX4hnAKehbqoOhFcLxgpODelxdSjVL5PaDDp4RTtEvr5eW0WvRB9TYv
la6fh4BQ9SgNSCg7PX2qENjl86eBKKNlakN28QdwUwAFHxj6y/GuE7te8JPdwdEFlCfDs6qyXbUa
ejUJEwi7bq66N6BA0rTfCxYleL/GeI+rJit0XKgwS9LPCa+VXpqND/ZdhIAMUKEAYpu+Mo2sdJZd
BJqyBi1PdIhGfdYcHHD4gqpkGz/WTdbnG3iPxPT0PDV+vKUWwBemX1JWiBmGg9DlGqUsCFfHfg01
aRy0GCT8HtCN6nO6/Z5wHr1bXilfW4S3Vle4s394ePjb3qb56ha9+Wt7K/jz8JD+Crs0D8Ov2wf7
O8Gf/7LxNt368GBrq9kJWoCpoU/svjw28QwB+/DO6jRXRTt6B15hc3RxM8sPsZMhlmuLIIFQHLy3
lXyWmMOz79HtkMKOyAv2T5VRmZkm2Dzc3eCb3TLdc4O/ZHEomqB3JZz9kR92c+PgqPPcMoTdNDdI
I3eer0cN8XG7ZIyPR9tbHyPHeV86zvvYcUqW01iNX07JamgYt5qAtU8hxXA0VbW60D5gjQiKecz5
A8+c/2dmWrbPuCP5mtrYr6ntySppHuRJD6XDpwaVzcpor7QaMaAB17q81z/zDBO7Qlj6eEtyY6te
+aXVQo5KiDrYDXylKlBPzOshy8dLznbrpri6ghHSM+NSBey2Z7WHIxbjiO89q+P7oTkbgZ8x8MrT
ZvYM3EnbpPL+FNK8fU/zkd7mSWKHwNmy8AhIAT9IsgBxrOK04uAnOHkHis/HlLNYS38JSsyhcvpR
c0/ptf+ImJaAbqbYr5nlBpzYijEdbOI5MRpTaK1BW2WMtRT7tZIz8C34urXVLGPXWI3i7IT7X4CI
C68lowQkhzdtY/PnDKOX2qv+/yiOT41+Pzfbe75IeKViea/Myu+XE8T/l10AWvFYoky59krxtreb
u0fbO51w12eZSD+QE3xyJbnSNRWMzY1ZDMq0L96bu9/ayHv7NdOWlUJhS7BkNXcYc9nyGUwxBUiS
4tR5+Azs2f0r65/l9J2knnUQoc+BMFeBWAsbZHroDDrNx6Y5kEdi1Z3RsRjeDpRQ+roEVgIzpn1L
hn1zBXfxY3AzA/Qn0ngpb76Ta0K1BZeYkhDDoN4edTrvTk8+zd7MMZdtnugWmrS89MgLESIFFIt2
xC2hgnonD/IsSw/ODby8q10xa7WYHT5+dHBQM8PPA1ClmhIIty/pHLaIb+tf3wZI1QFHwPi+Ozi9
zQQWznCGpX+GltYUcEMvnaTMj9Uswc3Vn+FBUe0u9Lv39ZPS1rp7hU/5Gy0f/9LQtqMOmH8QwTEO
uvwGiNgYSvcrwg4logy2d9JFtT381B33HvqxbJGxFZ13/rLjfgoUwZ58xCqCK5VoVXDlfmxUF7h4
6zOSxCwMeU+6McoJ8mv2n8aie4wq6OI+VEBAbKIjECbP4bZ1Qgd81rfkU6d4naYyTFIsv5Tjs9WQ
gOP0duCHh3u9ej0rGvE3M2KVfxFyO6UX5WBS/O9/IV7TAqKQePKo5XlqEIyrRTTUNsqnoXxCbEjE
Cz8r76F9pWjeDBmfXZ+qweYs0LYqWyG1MWgUu0I75rwlQi1XvjxuUbK01t4vGzutLfP87Q9v2aM+
cok87rzlHR7OWR0alCxub6Su/vun9AucASNXh3HnLa45b3HNuYtrDnu3XlozYmnQn5avjVuULK7d
RzXIvjkYDbokRtyYLeUiI1fJ489b5r9svC1fJRqULPJfusdwsrnl0jDoXMRj1nIO7kmbkvUdstpO
lheLeDLovPVZfXfpAm2jkhUKZ3e7JQa6dl5jEGbldX9gPLj4LvWml898ISzSIr1Z8weP7yj/PklV
ZgCK3BtdDeUFqJvu4Kp7M7HKG7EOKttDD+lE7Y3gKWSUBKN8HmIE9gxZyW5k1UJD/wI7gnst6MGk
Luy5OKelNsMPTbzjVm7FLrf5lplgIESTx10EKJxG7hHJ1yQVib8LDV3g3Qab4FJQYp25kvt0UmDb
rBiQHY8d768gfg7wWVjUX4FHsRxunpSKxDWgXxDRk6G4sYpjWDLkAWg85987cSf17Zwh5Mj/ux20
HLv7bTwflhZxU/h/1GmA2pz7+IpA0+oVrWbZHHfhomlah+26Ob6cmhbdAtqfIY3zacQ0zcL5p3k5
4G7/NC//aV7+07y89Kd5+Zubl5/+9xh5Z7SzZeasWHvuQqahaPOQbtxdFL+3I4oBXtxNw/t/AVBL
AwQUAAAACAAZbI0xOyynxbgaAABkTwAACgAAAHNtYzkxMTExLmisW/9v2zqS/1kP6P9AvAVuk8Jt
LMfJS9tX3MqS3HhrS36S3KZ3OBiyrcTa2pJXkvPl9vZ/v5khKZGW03SBDdrAETUfDofznfTZ6zf/
pp9Xv7C3rNwu35nw83bN3rBtvCzykt3mBavWCRtb3jvThkHmwp9FllTMKdL7pEBKorbz3VOR3q0r
dmKfsl63a7KwirNVXKzYJEWwp7JKtiW8WOzyIq7SPGMn4SS0T4me/zjJfbLJd8mKLZ5YmG53m4R5
SfWQF9/ZJL5Llwfk3kSQ69Ob795dIoJbpN+RjfVmG8Prbnha8xut05LtivyuiLcMPt4WScLK/LZ6
iIvkA3vK92wJNEWySsuqSBf7KmFpxWBFZyCTbb5Kb58ICB7us1XC5VQlBSwxv6U/Pnkz9inJkiLe
sOl+sQHux+kyycqExTA3PinXtFQCQpIhchEKLtgwB2Ra6geWpCh4BiIvcek9OYlA7LCc9oKdxBUy
X7B8h4SnwPET28RVQ/v2WRk0S12xNCP4NWwGfABQWOdDutmwRcL2ZXK733QIA95mX0fRtT+LmOV9
Y1+tILC86NsHeLta5zAKW8qxcDtTgIa1FXFWPcESCGLiBvY10FiD0XgUfYOVsOEo8twwZEM/YBab
WkE0smdjK2DTWTD1Qxf0JUyQsYQQfiDpW9otEOYqqeJ0Uzar/wZbXAKHmxVbx/cJbPUyAZVesZgt
QZte3kVCiTd5dkdrhbcbcX5g6S3L8qrDHooUVKfK2/tL9M0ed9goW77tsIt3LEpI86ebeAk7G+4R
4fy822GDvKzwzYnFWLcH9vjGPO/+xtgstPRdvU2BfplnsOashKXdwdaCCqQZyGPLrQdUmcXLZVKW
qrXXqtiYfJlmd4i2TncskeaP2EW+2SQF7MWoQvWJuVnAFhOIVFUhR3Iv7/rgXZA3zir9Gik8CY6l
/smFPIC95AsxclvkW51DggEL38MW0Wg4sYGrKGd3wCnfzg5uCFp1kcSbzRNAZhXLMxCvNPXbFATC
TVrhiNv2w8PD23JbLt8u863CurUHFS9K+mxozsaAnxOWwKO/3Fdvk9WekesxnLiARVng1O7TDX9p
leHnv5TZluBZ46OuYdPygnuH7vmZeXnWNY0DiIkQOW0eGCZXxWbzVvDWMhGQL0eCn/55ffbqlz+l
tyCdWzYHeVPomF/P4Sk8go06ePrql7PXbMTFXuZb0Afu3aunXVIyRHv1C35GvH1Wpne41ct1XICM
Fk9V8uHIMFhvUcE4hIfVsXEyzRQmNIyVeEcwMkiWMQoLdHMRZ99ZCVID/c7uOo1mPT4+okBB8zLQ
F/OSjc58BrGnkuzKhcI65yN/7t5ErhcZ5qWc5WUh/vCHtl3oGWxjuSxScunSoDB21pZdMu57FvEC
mAXjgeWC3oKxJh3hp9Ab361JT4Qv7Agcm4EHiiEWJWTHaXYfb/YAlMj56dcgLtMl2g4nI3ewBsPs
kwgp6jXcnLAu+rxzdgoecJ0u15wJ8MPc5fAIj74RhA4mmu23C/JPwlEOLO/zPHTHrh3VqARxAkoU
b8qcdD0m2fPX5kjCPZlIW2App4qxRgDLOUU2wNPcpnf7AtUo5xGOh4qygtAMOQbsfIcrR4+c22Yj
XGNMQsoS0DVudUKTiz24rBQ0G0T5veSie3mXf+qH69vZa7EPwFOYbJJlxQIhmvdMOg3DeIIfRr+6
8AO/QI8ZH4JPhvGRr4pL/IAEBruP5+cdWle6SrIKnMuSe0IpFZiGjJ9rv6HslGGYfWL0jEUQ4cst
5Aw2jxM1p9z8cKu6jKk4kR3MA/cTM7qPxLcBKJVEEdGmCWSN9SGd61mDscspTST8uoacw2QPCXl2
CaMTjX1/ykl6SCIYBT3eVztIW3ZgROPBZ50G8hHbH3OqvjoRZkYgs2VC4WYDmR2ITKedWg4wSrRX
3UPaXbxi1SNEr3gLHud3dglWBV6vZA9nXR3G8+3ARhSz20KBhIPFu10CgQxeoqRDYuogE9+b2yEx
09dg4P1tnqUQdkoQXVGkuGOaBJzZdHyDuToSX8FGsYY6ydBrQNDeAzOrPVjFI+ShCU/XdZwwms7D
P9wIUGAhKgsQ83YlMgIBOwRHDkH9D4jsaYX5fJE3/JDKuNNruZM9HUcyA2+wxSZffod4kO8W8fK7
jhB+xTUB/dVx+pBiA9j6EFfl8FVBppMoMYCA7LFrBQZAvGarnHl+dD3yPpGOwxN0avBuvN9A/Esq
dHtNeQXUjWq/BxJGNH/M3DAa+d57xBOxE/aUM4Yqs0LnCX6XAiE8WH5PIDr9Z8uuHHdozcYR7Flj
LUyEqTMSEOQt1b580UrxXdg6K5qFaKzCfJThcB7dzMOZrdjiOAaXGt1QElfuyfuDfmg0ofdpPK8N
i8wxFEmntCWMWeDxhMvdIGb1qIFMZgoGGecEhJ3uVJTyZZgxLACgIo5zVa8AFBJXAEkuoi7hkUZm
Xsq5TVIiyBfsZtYgiVGF9EWj9hNFr8tX3NZ1qAQO5gH2BoFDZP1um7lFkcerFnPRDWhAoLie2j07
yW1SFAecja1ILKbXFXNUR7cCPh8VoR9GNtSBinsZY1y1uUOB4EXVk0Lh3tiopMKlIIH7iIoC9Zhg
MdY1xo4gWhCP0nvYUEih+QTAJvPvKZlYidilczeCgOV/BtK+IKVWRoYJCaQ+SYErwwyI0sNsDEYA
seBAnjMv8BSXET2yGRYKkAPUZhXwevLnI2DAI6AhNPhg4GZuDfwgUgwrxHTtFja9EE6e68AixxXo
1NNgEirG5QoPArVSWi73OVg+d2gqjTUGMzgMdSUWVGDDu4pSosYYWmGGM80DnghVo+GQp2XwD4A6
Mj6Lyls6MJ2NMApG07mIeT3FQyMr2K+AYIHBjgo/kMRREBIdOL7BMRAKnSQ2pKcqVGq6jjIcjaO5
bal6XYNAnUqJ7yaJySubPbYA+6K0uBVIaV3+MArCSCgRpTtFUqL/ltm1qFXwzwzr0U07cASHgUNn
WPh940QTJPu/enNOdZ5EBHukpeGqUgo44FZiyLZLiBGJUO7a2l5SatufeZEbNNHiUiBMki3Utlr1
/yLYZKRayJVuaGfT9dO/YGxTW4Gy9IFw6rpOO6OYXn/j9REDhZ4sdtxq3uq0DqRH7aSmIcUs4o3I
Iia60QG15XE5XT1Dbe2r/I2X3OVVij65DTAOb6x5eD2MjAsEGKSoUDlkCOltxcZhz+qMQxN/dS18
vikXLfoBp++p9NhIAeoBUuOv7uCQmhG168xh5fDfOEHBnpLvdx32sRaZH/y55E0Kkz/YpFCN8JDS
BgvckJBMBSkAMynu1ZjVTE0v97RpX55k6BDZuUKm5nqakGsiSBOCG6LrK3SQ54BpBjfCDbF8udzr
8VURE1FfHJGR4HZ5nN2IT3upT/vihILb31RJvkAm88YTqZrgOk6UBbDff2ea0p2qLwwdZXxQj9cG
Jj6jwZzKvgxWplCzok3aqPKF2GvRckGNPFL+Eq0FOzag+l5NWAeh4nvcOjjbovyvHU/jKEyN3va9
4ehTA9FtDbk30RwMVIks5sfkEbjCbG4yGnVY92Oaib/BR7UAPk1tLwrGSlQZYRoCHpdnIStMT0oq
SDN6s4Xg+fOv1uhILZVBtfAI5S9kBhiM0IFjP4uNQost9mV7LZDeT/2vLhYJTEQmidalQgHbTNiW
XvFezSZ/YLv8ISmkKyTpOqLQwZdxMFm92e+wv91IocO+IkshsdShZnSzwI8A2+KtDmZHeD2tN3aA
kcparQrsa7ejgLa5xsAKXa2OESAjyBzv0xX2kw+hyuewLMcJug1YXx8xtQCojvSakauagebAgXou
Ly7k01QPZo2WPxMNdXI7Giv0tiJ6HLC/zAeWI/JlpdpfxLzNIOtObKvJQxQdwppFPkwA2UXoMh7d
FJwKk7a7RAJABoXtwRgiHeYF1HLUWR27asfnqnukAzFGD8pLKLK9Yr+rdBC9bdQ/BqKWFDmvKI5C
RRo/vWNQdcH1Q55cdxr4E9n35HrEzpTeFH8BhQRlHvsP7JUUyeE+jn3LERpdc4LJXAGpaQ1B1ls0
Sq1ChJEfyG6ahkDTNcdJJUfhiLXSTSYzYHi7RZNuK15P867w7tyeOEfd68SeD2bhN8NQO3qY9FLJ
KfSEOtDY9lrm2IRVCx8E8PypAVHv9995lPVy5u+atcIL1njs28aJiW9QDu4HPDkRDWnI3nsXl9SL
a1cWE0whQ6jiT3pyBsxNKhIBCCbNUkjTNjJx1sgm/hfXODmv5w0gHb5PeO6PkTirmmJGW5I0I2ac
9A+pUeRSMC8jDQPYuc/YFTq5UJA4ucgLwCVPvabG0Ohd74+ZO4NVXMrVu9nf98mezy0AqFJp9V9x
HWEU3QxHQ984+U2XHnXEbhiOlbVWTTmcx7flBb0ypp7izxq/DilCvpQhv8QI9RKQpRYc580C4PnQ
Go2pSuAtFauGHsbpBvVQlid8KWxKR0cvWURAMlHiCGJP9qDxi4QsmFGfB4+zjhBNptE3o2lLyKnd
7a56qhmK/iWGooYhhbefYEoQRg1ThjK5ztI0T58pJ3VmppG6H0okpQH7i2E0SYv5UXZgIK7EmIXV
Thgf6LQYoUaezZQoh6UW6P+ySLZoQ6TTgk3YZGzoibOsQ/YsWTqqMQ6o6044PyxHudUCcOIqflEZ
HSuyjmULIxlNRBv3zFp+z/IHUMK7Y6mDDjryIj32t0Ancfn9xZ0ZTRQUR4GfzCcOzEEbgwLBWnYy
qvGYedVMpZG5mHhwSh6d3bjYPMlq/zkiSAo5DQ/D2CPDi0B4bQE+Tou8ypeQEV2Dq9zA7CWUEWqD
EDGCm7n/JfAEjqniiMkLajAW+6zUCCmYCLLulSR7QA2IG89TJOAkS0qO20ELYaCyJJuRSH2JlN6q
vpHd5RCLE25HOrkgpPBfKz0XmCYx2rVayjzYH5GvDOx1ry+i9uGRlPhcb9fYVkjKZR4G92aoV/vo
1tC5cZhJ10P92gFI3uIMUkgyVGL8FkqURsdOoAw7fZbL0UhvKtVBCgYm4WfIFEMs1hvP4KSlSBBp
RPQVqDO+L7D5BxntOt7c4hHYAZzji8SK1AMeMZ8fN/KW7MHb9viz0WSB+LaNB1kdKpUmDgwfwo9k
zJMEowzQJcGoxY2hpHkNN/J9vwliyT3viLb9gC7NwP2iliIM3jph6/Q9vy+QrhjDmvE9WME9+xM7
FXU9zSHs2/7y7CTUDeX9Y8+P0A3THZN3ukcjx1G7SaWa4QPw3xmFtjhE0aqHVVou42KF3lmkL4sE
97Nd1RBUdA3p37U/5kjmkJwU8h+tIU1e55sV+U65PNkTaK/uN53/G9Ujd7l85MT29Wg6xyUb5+2H
faPffnhhXLQfXhqXrYeo5L8dezp0jKv2c9OE5++QN8xv0yUe0oNvwDs77DVt9zxdlf/NzAv2P+wj
Y/9gr34xvNl43GHqb3gIYsD9Zb/Sbtrvumf4u/drh4/11bG+fHqhPr2QTy/Vp5fy6W/KU1jPr3LW
K/350KlH3qkj5qMcOWD8cDX//MDoWBUA+JUT6XtLfry6wG6qdn2CRSEel9p42ZFbojYkTtJwqK/W
RpE8pGM41DsYorNIRkNds8sZIn6kb1fY0bkJQghinzyXzu6utHIMhgaB76AHFq5QH7McfkbTOxzx
HWcYWBPXaLpTi/3d+4NLhllyT+GYzj9SalIJq9PAIt8f+55skR8OgTHyE7L+wRge6I4E67qQYRBW
6wehcdIsHjuTckn8s5i3/oNmOm3O0DGrifAq26tfEigd2T9AO+AZ7JJ3dW6bV+fY3e1Q57VectMO
u/528Dpw/88PGngdy0RDCqLPyXGoU4Wq3QCS68bZbE/t+xwbCyOZUfO+JuekVAvJ+uXxdPDZMJpT
Vf72+PDORUPAT1mM5pjF/Cga4Jism93JblEeIcM+NL9IY9aZvjjQpJQ9E6cj2rlvTT11PENoT8Pk
lDqYTv6Q6eegDRmGS4gaQrc4JcbLPp3ypXXKseKpweo5vvmJH1qsLFGw4tX4PjY9HSpRiiYnVw4o
UFrXmG7wP4+QgzuIQnHZ4EoA8HQiFwed/J5BrTet6yAqJN7/qNXGPDJmW9N51Nc1BxjH1uybqM+W
8U7PdXTCm6GmRJLwRrtV9BLG9aFaCQyZlv0ExtBQPBZi0NHMv8DEta5oAuDnOQhnU35noy8QwCHe
s+3dVh62i05VXrEdFJPb40ikdpbNE8meQKKzHGydHWmbKVs8mQ/FRRhxqeUjNpqqhA2pvS/vgTzD
vzzLFLdoYFZNzX+weryiIa9BcNL7eAO5I56LHXn9r9ZApr2aqP8WL7BZBHnJKm27AyJ1b5pMy+TE
eHaT4d1Opc2JQsLigrd1hJGMxP1IpW9x4K9GjlkbCrF2QGYevt6rXz8/8npPmVw7CEYLtlZ4dSUt
eRF03HItp8bvt0a8advXi1oVysxHyOuyO7oS44GE2BTKrRYEqplmvMAeP8xcglul/pC4p0Fq1GZu
qIeDWK5JEDA6VmqRcV/TnL5N+XG50C9kufE+beKb+dA5cK4/AIDaG53xMZhrAVO72B/CXB+FMbs1
N7XZH4PhKM/wAiA1L72XQY5zYocTSzeMNsRVt/f2nNmT0DrUTCUIM+EzXLyVirQp3W87rqHBpAkt
FwQ5w1SnxNtNGGnpVTLmEnuOjVLrSY9+tisaTQeBcfipNk7zMPnBsbH3GSO+ZhPBIz9ZcsjzseE+
E3X/8bCPMDeTSMA0ZhFN69IAOXN+SC0ylt5z1FN+wkrpyxGEwbcpFLvc5iXC4GkXlyDVZUFRozij
rxfwz0cgZl5oO6FuY7NMUoCHomYQXgpDWYjVHMFx/xj/V6BbGgjU/TveePzfH8vBpuM1zbrCaHpi
XnTz9fYUM6AZ/tmlP49t9PjLuKubFUwdgnfbLNdsg187BB+z2i/5FxP6by9WiyMwEcDMw+uRvB5T
F3iiizMmIGv1t315mCLX5BMr5MH43D72SjBs3uBRQN3sAJzh2RBv3uFXDbQK4Rm177UmqYOM2TaJ
3tya+mOR6TbpAgbuab6JC7RcOy+K5AW972FQFnrfZA9/5QH5B1QTpRPHaepLvDIcyy+tYVMPsqGq
vd09bGhOnJGvpRBNQ7ukm7b4TUTMn/BFtttvyiRvZ8BiX0/wZE0BoMHTZ3yY0lE3+V1mHeuwXX/a
JseGrOZ4qHNAX1PkcXiF38pb1mehsdJBlhjgv/CISvc85L28/Lncjej8MAy/ebKW53RO4yAob9zg
fd7yKVu26e2vgcOdqiQeZTx96w8uBjwTUG8QF49tjDAkiCZ59nIUVgGGdgsfMNt9EcMVGH0FA2PQ
zyMEYAq61wsSfjGntoXnxSiT0trVSeV/liKcOo57UKUpCQNWprwwFnG7XaoiCgbzGqZfbx9+C1Be
P6wLxSaVlSp5JnT14MxHnQS9U63f5KD0o6ImatPXPn8QuYWhcC+GTaqXvwn1kz/8u3MjJtimLxyK
L7mCJ9vG3+nL3ElcYloNT1Y5vfOAX+6CkmiLtQIg4Je7Nvit8s0Tr5TwPnmy6oDF7RL8JL/r9W/9
bqW46vaalfyWW9y4PvzmVuf/e7m2njSCKPxsE//DJCYNVBoK+mBjfOCyEBIQsqxUkyYNclEiAoFF
JdX+9p7L3PYs0Jo05Ulnvj1z2dm5nPN9Y6R12ndu3o2QwmVesuhzna/j54x6yanJvD8cLtVxQlqX
PVdvxmNJbjfDV+nPHEfFaMFdwiOODlsp34HYJV4ALtb4drEOP78ffjg4SEg66flzSpeVLmY5nUq4
gCJvM67mHGNUPuT1QkEhnABNBTQm57Y8owDz5jd1aKI4ibZadfG+1ibbC8vc/2vwxwv16/0t/vOg
+5sffRNVbniii1Ysi3QSJcPot72JYRUnxWQgixaVcmFb1h3OYE3bqBESpVYWocOUjLjvLxYbG5Vx
xByDdQHcnLrVUt8GL59QuYfJ4IEqpQ0s7YMUqeYiOr7PtXBm1vAKrb6rf/69++OpgYT58KoT0VSr
FOwYbA+pV9FAncC9A//guDAtMf7po8kYzBseZfemW4maZsqFlnyCdzqA9azPk7PRFqw2q0E8db5N
LeSlUPbzCvW3S57izYkunpMxo9XELGwTbNhWC5jH7L0Yzm2NQSK8yoG2MjFfEkA2YGlbTy1/abrx
fTFgSFctpnPocDPrP/rKZJ276Mf3ZIx1vWSw1m7jETa/WM4HecDBwecpP4rvr/OQg2Cf+Ysu6lZF
mV8GE8pX3ePCydnXLKfBStdfwuq27C83xL7C+zLQRbhR6xn0ELmLbEBAW4Q3VWvbeECXa4v3HKz8
mwc8fPdbLwhzB4jmW1fcFSE9fckCyigST6CmkR/Zql9kTrvFw+hCESVVCFm+ZdJL2qiCc+LbJ2Dz
3dYFUNzYqTwtBDk1l0GdjCacAiNZfMiqUkKGmh6xp7YhRQ64cAPvLkbQROaFi2p4xkuDGEm9e2yX
PNsavdu03mJzXAd31ob6ZREsGGZzNa0Prjh9sMM1mhjoI0s1khIZtZwPCoOgFbQYhDeJlNfjMSBZ
SuMBo3ZEODo9zmNowy5kM6iWGKdPJ/CNQtrnUhJT3oYpexgMCodBT0S4Khjzt9SBRtVORbRsBuUr
2PvxS0we7fiOgtv13d1kdue/+KD+o9zlXvJ0AAIRVRghNegCFmhDTv4qAKG2I4R8AlWJQoZptrDI
bjU4Ny13kqV1ksX5ciZZZK1uivSO/LKfSqafHCFeQBql8EuON/ApvvuXNLawC1tQaXBxF7gosPUO
11NQ3lO93LRN3tIjLd13HvdYIDqXjEjwSAWmpqvi2JHSSKSNMA9Q5FbNHI1cPtkjerDJs79sR6R7
WXKtAmj1Bl2YEl7cA5ddDfCTPfCTNPx0D/w0NdLNUN/CxZKDPeiZwf4kp0L6NmFDo79OQwqSiGv9
LgytxssnN1AU8rzccWFwAcEAkIWkXgcdUKsFC4C/U7lFL7cockvVis21sRnPAS7gYdB6Fx6dhX77
PNefrCd6xHZAZaVx+2ubJH0CPPuLJ3CLuvsR9gccjWAaGB/SVL93J7z955XYRP5fcBmFN2gLphQ1
Gz3DoTWGlZKkz5pCP4UNnKFQcOkko0hugJXNQ5Ya2Tf3FVla2m9QSwECFAAUAAAACAAZbI0x2COC
/s8bAACTSQAABwAAAAAAAAABACAAtoEEAAAAQ09QWUlOR1BLAQIUABQAAAAIABlsjTFtqBd1eAEA
AHgCAAAIAAAAAAAAAAEAIAC2gfgbAABtYWtlZmlsZVBLAQIUABQAAAAIAOR4jTHi8LByDRYAAFNO
AAAKAAAAAAAAAAEAIAC2gZYdAAByZWFkbWUudHh0UEsBAhQAFAAAAAgAGWyNMWZFWiQCZQAAdZ8B
AAoAAAAAAAAAAQAgALaByzMAAHNtYzkxMTExLmNQSwECFAAUAAAACAAZbI0xOyynxbgaAABkTwAA
CgAAAAAAAAABACAAtoH1mAAAc21jOTExMTEuaFBLBQYAAAAABQAFABMBAADVswAAAAA=


--=-Prjo5kPrED460n4iSWkI
Content-Disposition: attachment; filename=smslan91c111.patch
Content-Type: text/x-patch; name=smslan91c111.patch; charset=utf-8
Content-Transfer-Encoding: 7bit

This patch changes the SMSC-authored LAN91C111 Linux Ethernet driver
to work with the AMD Alchemy Au1x00 SOCs, utilizing the static bus
controller.

This patch is developed against SMSC LAN91C111 Linux driver 2.01,
which was obtained here:

  http://www.smsc.com/main/catalog/lan91c111.html


--- linux26.cvs/drivers/net/Kconfig	2005-01-24 22:28:23.000000000 -0600
+++ linux26.amd/drivers/net/Kconfig	2005-02-24 15:45:40.000000000 -0600
@@ -472,6 +472,14 @@ config MIPS_AU1X00_ENET
 	  If you have an Alchemy Semi AU1X00 based system
 	  say Y.  Otherwise, say N.
 
+config MIPS_SMSCLAN91C111_ENET
+	bool "SMSC LAN91C111 on AMD Alchemy Static Bus support"
+	depends on NET_ETHERNET && SOC_AU1X00
+	select CRC32
+	help
+	  Use SMSC LAN91C111 with AMD Alchemy Statis Bus
+	  say Y.  Otherwise, say N.
+
 config SGI_IOC3_ETH
 	bool "SGI IOC3 Ethernet"
 	depends on NET_ETHERNET && PCI && SGI_IP27

--- linux26.cvs/drivers/net/Makefile	2005-01-13 08:06:10.000000000 -0600
+++ linux26.amd/drivers/net/Makefile	2005-02-24 15:46:18.000000000 -0600
@@ -166,6 +166,7 @@ obj-$(CONFIG_EQUALIZER) += eql.o
 obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o
 obj-$(CONFIG_MIPS_GT96100ETH) += gt96100eth.o
 obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o
+obj-$(CONFIG_MIPS_SMSCLAN91C111_ENET) += smc91111.o
 obj-$(CONFIG_SGI_IOC3_ETH) += ioc3-eth.o
 obj-$(CONFIG_DECLANCE) += declance.o
 obj-$(CONFIG_ATARILANCE) += atarilance.o


--- linux.org/drivers/net/smc91111.c	2004-12-13 13:32:50.000000000 -0600
+++ linux.amd/drivers/net/smc91111.c	2005-03-03 10:40:43.000000000 -0600
@@ -64,11 +64,11 @@
 static const char version[] =
 "SMSC LAN91C111 Driver (v2.01), (Linux Kernel 2.4 + Support for Odd Byte) 12/13/04\n\n";
 
-#ifdef MODULE
+#include <linux/config.h>
 #include <linux/module.h>
+#ifdef MODULE
 #include <linux/version.h>
 #endif
-
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/types.h>
@@ -95,6 +95,65 @@ static const char version[] =
 #include <linux/sysctl.h>
 #endif
 
+#if defined(CONFIG_SOC_AU1X00)
+#define SMC_DEBUG 1 // Must be defined in makefile
+
+#ifdef CONFIG_MIPS_PB1550
+#include <asm/mach-pb1x00/pb1550.h>
+#endif
+#ifdef CONFIG_MIPS_PB1200
+#include <asm/mach-pb1x00/pb1200.h>
+#endif
+#ifdef CONFIG_MIPS_DB1200
+#include <asm/mach-db1x00/db1200.h>
+#endif
+#ifdef CONFIG_MIPS_FICMMP
+#include <asm/mach-pb1x00/ficmmp.h>
+#endif
+
+#include <asm/mach-au1x00/au1000.h>
+#undef inb
+#undef inw
+#undef outb
+#undef outw
+
+#define inb(x)		au_readb(x)
+#define inw(x)		au_readw(x)
+#define outb(d,x)	au_writeb(d,x)
+#define outw(d,x)	au_writew(d,x)
+
+/* Can't use io.h version since it inlines incorrect inw() and outw() */
+#undef insw
+#define insw auinsw
+static inline void auinsw(unsigned long port, void *addr, unsigned int count)
+{
+    while (count--) {
+        *(u16 *)addr = inw(port);
+        addr += 2;
+    }
+}
+
+#undef outsw
+#define outsw auoutsw
+static inline void auoutsw(unsigned long port, void *addr, unsigned int count)
+{
+    while (count--) {
+        outw(*(u16 *)addr, port);
+        addr += 2;
+    }
+}
+
+/* extern functions */
+extern int get_ethernet_addr(char *ethenet_addr);
+
+/* Compiled-in defaults can be over-ridden at boot-time by board setup code */
+uint32_t au1xxx_smc91111_base = KSEG1ADDR(AU1XXX_SMC91111_PHYS_ADDR);
+int au1xxx_smc91111_irq = AU1XXX_SMC91111_IRQ;
+int au1xxx_smc91111_nowait = 1;
+
+#define RPC_DEFAULT (RPC_ANEG | (RPC_LED_100_10 << RPC_LSXA_SHFT) | (RPC_LED_TX_RX << RPC_LSXB_SHFT))
+#endif /* end CONFIG_SOC_AU1X00 */
+
 #include "smc91111.h"
 /*------------------------------------------------------------------------
  .
@@ -106,7 +165,9 @@ static const char version[] =
  . Do you want to use 32 bit xfers?  This should work on all chips, as
  . the chipset is designed to accommodate them.
 */
+#if !defined(CONFIG_SOC_AU1X00)
 #define USE_32_BIT 1
+#endif
 
 
 /*
@@ -368,7 +429,7 @@ static void smc_phy_configure(struct net
 /*
  . Handles the actual interrupt
 */
-static void smc_interrupt(int irq, void *, struct pt_regs *regs);
+static irqreturn_t smc_interrupt(int irq, void *, struct pt_regs *regs);
 /*
  . This is a separate procedure to handle the receipt of a packet, to
  . leave the interrupt code looking slightly cleaner
@@ -546,7 +607,7 @@ static void smc_reset( struct net_device
 */
 static void smc_enable( struct net_device *dev )
 {
-	unsigned short ioaddr 	= dev->base_addr;
+	unsigned int ioaddr 	= dev->base_addr;
 	struct smc_local *lp 	= (struct smc_local *)dev->priv;
 
 	PRINTK2("%s:smc_enable\n", dev->name);
@@ -701,7 +762,7 @@ static int crc32( char * s, int length )
 static int smc_wait_to_send_packet( struct sk_buff * skb, struct net_device * dev )
 {
 	struct smc_local *lp 	= (struct smc_local *)dev->priv;
-	unsigned short ioaddr 	= dev->base_addr;
+	unsigned int ioaddr 	= dev->base_addr;
 	word 			length;
 	unsigned short 		numPages;
 	word			time_out;
@@ -823,7 +884,7 @@ static void smc_hardware_send_packet( st
 	byte	 		packet_no;
 	struct sk_buff * 	skb = lp->saved_skb;
 	word			length;
-	unsigned short		ioaddr;
+	unsigned int	ioaddr;
 	byte			* buf;
 
 	PRINTK3("%s:smc_hardware_send_packet\n", dev->name);
@@ -935,7 +996,7 @@ static void smc_hardware_send_packet( st
 int __init smc_init(struct net_device *dev)
 {
 	int i;
-	int base_addr = dev ? dev->base_addr : 0;
+	unsigned int base_addr = dev ? dev->base_addr : 0;
 
 	PRINTK2("CARDNAME:smc_init\n");
 
@@ -1118,6 +1179,7 @@ static int __init smc_probe(struct net_d
 	   so I can access the base address register */
 	SMC_SELECT_BANK(1);
 	base_address_register = inw( ioaddr + BASE_REG );
+#ifndef CONFIG_SOC_AU1X00
 	if ( ioaddr != ( base_address_register >> 3 & 0x3E0 ) )
 	{
 		printk("CARDNAME: IOADDR %x doesn't match configuration (%x)."
@@ -1128,6 +1190,7 @@ static int __init smc_probe(struct net_d
 		retval = -ENODEV;
 		goto err_out;
 	}
+#endif
 
 	/*  check if the revision register is something that I recognize.
 	    These might need to be added to later, as future revisions
@@ -1157,6 +1220,7 @@ static int __init smc_probe(struct net_d
 	/*
  	 . Get the MAC address ( bank 1, regs 4 - 9 )
 	*/
+#ifndef CONFIG_SOC_AU1X00
 	SMC_SELECT_BANK( 1 );
 	for ( i = 0; i < 6; i += 2 )
 	{
@@ -1166,6 +1230,10 @@ static int __init smc_probe(struct net_d
 		dev->dev_addr[ i + 1] = address >> 8;
 		dev->dev_addr[ i ] = address & 0xFF;
 	}
+#else
+		/* Obtain address from Boot PROM (no EEPROM) */
+		get_ethernet_addr(dev->dev_addr);
+#endif
 
 	/* get the memory information */
 
@@ -1445,7 +1513,7 @@ static void smc_timeout (struct net_devi
  .   and finally restore state.
  .
  ---------------------------------------------------------------------*/
-static void smc_interrupt(int irq, void * dev_id,  struct pt_regs * regs)
+static irqreturn_t smc_interrupt(int irq, void * dev_id,  struct pt_regs * regs)
 {
 	struct net_device *dev 	= dev_id;
 	int ioaddr 		= dev->base_addr;
@@ -1466,7 +1534,7 @@ static void smc_interrupt(int irq, void 
 	if (dev == NULL) {
 		printk(KERN_WARNING "%s: irq %d for unknown device.\n",
 			dev->name, irq);
-		return;
+		return IRQ_RETVAL(1);
 	}
 
 /* will Linux let this happen ??  If not, this costs some speed
@@ -1490,6 +1558,18 @@ static void smc_interrupt(int irq, void 
 	outb( 0, ioaddr + IM_REG );
 
 
+	#if defined(CONFIG_MIPS_FICMMP)
+		//Check if the unit is still docked
+		if(((*((u32*)0xB170000C)) >> 15 & 0x01) == 0)
+		//if(au1xxx_gpio_read(215) == 0)	//Ugh!  why isn't this symbol getting exported?!?!?
+		{
+			//Disable the ethernet IRQ.  Removing from dock pulls IRQ high (always on!)
+			free_irq(devSMC91111.irq, &devSMC91111);
+			mask = 0;
+			goto no_device;
+		}
+	#endif
+
 	/* set a timeout value, so I don't stay here forever */
 	timeout = 4;
 
@@ -1500,6 +1580,9 @@ static void smc_interrupt(int irq, void 
 		if (!status )
 			break;
 
+		// Acknowledge the interrupt
+		outb(status, ioaddr + INT_REG );
+
 		PRINTK3(KERN_WARNING "%s: Handling interrupt status %x \n",
 			dev->name, status);
 
@@ -1512,8 +1595,6 @@ static void smc_interrupt(int irq, void 
 			PRINTK2(KERN_WARNING "%s: TX ERROR handled\n",
 				dev->name);
 			smc_tx(dev);
-			// Acknowledge the interrupt
-			outb(IM_TX_INT, ioaddr + INT_REG );
 		} else if (status & IM_TX_EMPTY_INT ) {
 			/* update stats */
 			SMC_SELECT_BANK( 0 );
@@ -1534,8 +1615,6 @@ static void smc_interrupt(int irq, void 
 			SMC_SELECT_BANK( 2 );
 			PRINTK2(KERN_WARNING "%s: TX_BUFFER_EMPTY handled\n",
 				dev->name);
-			// Acknowledge the interrupt
-			outb( IM_TX_EMPTY_INT, ioaddr + INT_REG );
 			mask &= ~IM_TX_EMPTY_INT;
 			lp->stats.tx_packets += lp->packets_waiting;
 			lp->packets_waiting = 0;
@@ -1559,25 +1638,22 @@ static void smc_interrupt(int irq, void 
 		} else if (status & IM_RX_OVRN_INT ) {
 			lp->stats.rx_errors++;
 			lp->stats.rx_fifo_errors++;
-			// Acknowledge the interrupt
-			outb( IM_RX_OVRN_INT, ioaddr + INT_REG );
 		} else if (status & IM_EPH_INT ) {
 			PRINTK("%s: UNSUPPORTED: EPH INTERRUPT \n",
 				dev->name);
 		} else if (status & IM_MDINT ) {
 			smc_phy_interrupt(dev);
-			// Acknowledge the interrupt
-			outb(IM_MDINT, ioaddr + INT_REG );
 		} else if (status & IM_ERCV_INT ) {
 			PRINTK("%s: UNSUPPORTED: ERCV INTERRUPT \n",
 				dev->name);
-			// Acknowledge the interrupt
-			outb( IM_ERCV_INT, ioaddr + INT_REG );
 		}
 	} while ( timeout -- );
 
 
 	/* restore register states */
+#if defined(CONFIG_MIPS_FICMMP)
+no_device:
+#endif
 
 	SMC_SELECT_BANK( 2 );
 
@@ -1590,7 +1666,7 @@ static void smc_interrupt(int irq, void 
 
 	//dev->interrupt = 0;
 	PRINTK3("%s: Interrupt done\n", dev->name);
-	return;
+	return IRQ_RETVAL(1);
 }
 
 /*-------------------------------------------------------------
@@ -1874,7 +1950,7 @@ static struct net_device_stats* smc_quer
 */
 static void smc_set_multicast_list(struct net_device *dev)
 {
-	short ioaddr = dev->base_addr;
+	int ioaddr = dev->base_addr;
 
 	PRINTK2("%s:smc_set_multicast_list\n", dev->name);
 
@@ -1930,7 +2006,7 @@ static void smc_set_multicast_list(struc
 	}
 }
 
-#ifdef MODULE
+//#ifdef MODULE
 
 static struct net_device devSMC91111;
 int io = 0;
@@ -1944,7 +2020,7 @@ MODULE_PARM(nowait, "i");
 /*------------------------------------------------------------
  . Module initialization function
  .-------------------------------------------------------------*/
-int init_module(void)
+int __init smc91111_init_module(void)
 {
 	int result;
 
@@ -1954,9 +2030,21 @@ int init_module(void)
 		CARDNAME": You shouldn't use auto-probing with insmod!\n" );
 
 	/* copy the parameters from insmod into the device structure */
+#ifdef CONFIG_SOC_AU1X00
+	if (au1xxx_smc91111_base == 0)
+	{
+		printk(KERN_WARNING
+		CARDNAME": Wrong SMC91111 Base Address!\n" );
+		return -ENODEV;
+	}
+	devSMC91111.base_addr	= au1xxx_smc91111_base;
+	devSMC91111.irq		= au1xxx_smc91111_irq;
+	devSMC91111.dma		= au1xxx_smc91111_nowait;
+#else
 	devSMC91111.base_addr	= io;
 	devSMC91111.irq		= irq;
 	devSMC91111.dma		= nowait; // Use DMA field for nowait		
+#endif
 	devSMC91111.init	= smc_init;/* Kernel 2.4 Changes - Pramod */
 	if ((result = register_netdev(&devSMC91111)) != 0)
 		return result;
@@ -1967,7 +2055,7 @@ int init_module(void)
 /*------------------------------------------------------------
  . Cleanup when module is removed with rmmod
  .-------------------------------------------------------------*/
-void cleanup_module(void)
+void __exit smc91111_cleanup_module(void)
 {
 	/* No need to check MOD_IN_USE, as sys_delete_module() checks. */
 	unregister_netdev(&devSMC91111);
@@ -1979,8 +2067,10 @@ void cleanup_module(void)
 		kfree(devSMC91111.priv); /* Kernel 2.4 Changes - Pramod */
 }
 
-#endif /* MODULE */
+//#endif /* MODULE */
 
+module_init(smc91111_init_module);
+module_exit(smc91111_cleanup_module);
 
 #ifdef CONFIG_SYSCTL
 
@@ -2065,7 +2155,7 @@ static const char smc_info_string[] =
  . Sysctl handler for all integer parameters
  .-------------------------------------------------------------*/
 static int smc_sysctl_handler(ctl_table *ctl, int write, struct file * filp,
-				void *buffer, size_t *lenp)
+				void *buffer, size_t *lenp, loff_t *fpos)
 {
 	struct net_device *dev = (struct net_device*)ctl->extra1;
 	struct smc_local *lp = (struct smc_local *)ctl->extra2;
@@ -2294,7 +2384,7 @@ static int smc_sysctl_handler(ctl_table 
 	val = *valp;
 
 	// Perform the generic integer operation	
-	if ((ret = proc_dointvec(ctl, write, filp, buffer, lenp)) != 0)
+	if ((ret = proc_dointvec(ctl, write, filp, buffer, lenp, fpos)) != 0)
 		return(ret);
 
 	// Write changes out to the registers


--- linux.org/drivers/net/smc91111.h	2005-03-02 13:48:34.000000000 -0600
+++ linux.amd/drivers/net/smc91111.h	2005-03-02 13:48:48.000000000 -0600
@@ -89,7 +89,7 @@ typedef unsigned long int 		dword;
 #define	TCR_CLEAR	0	/* do NOTHING */
 /* the default settings for the TCR register : */ 
 /* QUESTION: do I want to enable padding of short packets ? */
-#define	TCR_DEFAULT  	TCR_ENABLE 
+#define	TCR_DEFAULT  	(TCR_ENABLE | TCR_SWFDUP)
 
 
 // EPH Status Register
@@ -151,7 +151,9 @@ typedef unsigned long int 		dword;
 #define RPC_LED_100	(0x05)	// LED = 100Mbps link dectect
 #define RPC_LED_TX	(0x06)	// LED = TX packet occurred
 #define RPC_LED_RX	(0x07)	// LED = RX packet occurred
+#ifndef RPC_DEFAULT
 #define RPC_DEFAULT (RPC_ANEG | (RPC_LED_100 << RPC_LSXA_SHFT) | (RPC_LED_FD << RPC_LSXB_SHFT) | RPC_SPEED | RPC_DPLX)
+#endif
 
 /* Bank 0 0x000C is reserved */
 

--=-Prjo5kPrED460n4iSWkI--


From jerry@izmiran.rssi.ru Fri May  6 17:18:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 17:19:08 +0100 (BST)
Received: from cygnus.izmiran.rssi.ru ([IPv6:::ffff:193.232.24.21]:58039 "EHLO
	cygnus.izmiran.rssi.ru") by linux-mips.org with ESMTP
	id <S8226013AbVEFQSx>; Fri, 6 May 2005 17:18:53 +0100
Received: from [127.0.0.1] (IDENT:10003@localhost [127.0.0.1])
	by cygnus.izmiran.rssi.ru (8.12.4/8.12.4) with ESMTP id j46GIOcs021931;
	Fri, 6 May 2005 20:18:31 +0400
Date:	Fri, 6 May 2005 19:19:49 +0300
From:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: "Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Organization: Home
X-Priority: 3 (Normal)
Message-ID: <801670482.20050506191949@izmiran.rssi.ru>
To:	Pete Popov <ppopov@embeddedalley.com>
CC:	linux-mips@linux-mips.org
Subject: Re[2]: dbau1200 ethernet driver?
In-Reply-To: <1115394400.5785.3.camel@localhost.localdomain>
References: <261758805.20050506155322@izmiran.rssi.ru>
 <1115394400.5785.3.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit
Return-Path: <jerry@izmiran.rssi.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7888
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@izmiran.rssi.ru
Precedence: bulk
X-list: linux-mips

>[In reply to "dbau1200 ethernet driver?" from Pete Popov <ppopov@embeddedalley.com> to Ruslan V.Pisarev <jerry@izmiran.rssi.ru>  06/05/2005 18:46]

PP> The smc91x.c driver. However, I don't remember if that driver was
PP> tested.  The board was tested with a different smc driver which I
PP> couldn't push in the tree because it was old and would conflict with the
PP> smc91x.c.

Ok. But as I replied earlier, this driver is not in MIPS architecture
tree. And I suspect it needs some additional configurations and
modifications..
May I expect any solution in the near future or better do some digging by
myself? (alas I have not much expirience with this stuff)


   ()_()
--( °,° )---[21398845]-[jerry¤wicomtechnologies.com]-
  (") (")                 -<The Bat! 3.0.1.33>- -<06/05/2005 19:07>-


From geert@linux-m68k.org Fri May  6 17:47:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 17:48:10 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:31118 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226017AbVEFQry>;
	Fri, 6 May 2005 17:47:54 +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 j46GliUu013723;
	Fri, 6 May 2005 18:47:45 +0200 (MEST)
Date:	Fri, 6 May 2005 18:47:41 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
cc:	"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: ATA devices attached to arbitary busses
In-Reply-To: <20050506152006Z8225995-1340+6646@linux-mips.org>
Message-ID: <Pine.LNX.4.62.0505061846170.5272@numbat.sonytel.be>
References: <20050506152006Z8225995-1340+6646@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7889
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 6 May 2005, Bryan Althouse wrote:
> All IDE drives should have the identical memory map.  But, the kernel does
> not communicate directly with the drive, it communicates though an IDE host
> adaptor (which may have different implementations).  If the host adaptor's
> memory map "matches" that of the IDE drive spec, then you consider it to be
> a "standard port layout"?  Since my host adaptor will be implemented in an
> FPGA, if I give it the IDE memory map defined in ide.h, then your example
> code will be applicable.
> 
> The memory map defined in ide.h makes sense to me (it seems to match the IDE
> drive memory map) until we get down to offset 6 (IDE_SELECT_OFFSET).  From
> here down, I have trouble matching the #define names with the register
> names/descriptions from the IDE spec.  Also, I am puzzled as to why there
> are 10 registers defined in ide.h when my IDE spec only shows 9.  The IDE
> spec that I am referencing looks like this:
> 
> CS0   CS1    DA2   DA1   DA0   READ              WRITE
> A     N      0     0     0     Data              Data
> A     N      0     0     1     Error             Features
> A     N      0     1     0     Sector Count      Sector Count
> A     N      0     1     1     Sector Number     Sector Number
> A     N      1     0     0     Cylinder Low      Cylinder Low
> A     N      1     0     1     Cylinder High     Cylinder High
> A     N      1     1     0     Device/Head       Device/Head
> A     N      1     1     1     Status            Command
> N     A      1     1     0     Alternate Status  Device Control (IRQ en/dis)
> 
> 
> ide.h shows the following offsets:
> 
> #define IDE_DATA_OFFSET		(0)
> #define IDE_ERROR_OFFSET	(1)
> #define IDE_NSECTOR_OFFSET	(2)
> #define IDE_SECTOR_OFFSET	(3)
> #define IDE_LCYL_OFFSET		(4)
> #define IDE_HCYL_OFFSET		(5)
> #define IDE_SELECT_OFFSET	(6)
> #define IDE_STATUS_OFFSET	(7)
> #define IDE_CONTROL_OFFSET	(8)
> #define IDE_IRQ_OFFSET		(9)
> 
> Do you know of an IDE host adapter chipset which is standard?  If someone
> knows of a part number, I could look up its datasheet.  This would probably
> clear up my confusion.  Thanks again!  

This is not the direct `memory map' of the IDE drive's registers! It's an
indirect map, cfr. e.g.

    #define IDE_DATA_REG            (HWIF(drive)->io_ports[IDE_DATA_OFFSET])

So the actual register is found by looking up offset IDE_DATA_OFFSET in the
array HWIF(drive)->io_ports[].

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 bryan.althouse@3phoenix.com Fri May  6 18:09:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 18:09:38 +0100 (BST)
Received: from rwcrmhc14.comcast.net ([IPv6:::ffff:216.148.227.89]:56298 "EHLO
	rwcrmhc14.comcast.net") by linux-mips.org with ESMTP
	id <S8226019AbVEFRJX>; Fri, 6 May 2005 18:09:23 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc14) with SMTP
          id <2005050617091401400881mhe>; Fri, 6 May 2005 17:09:15 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Geert Uytterhoeven'" <geert@linux-m68k.org>
Cc:	"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: ATA devices attached to arbitary busses
Date:	Fri, 6 May 2005 13:09:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVSW1kVhIWtjtPyQ66P7vSJUfe3NQAAEGqQ
In-Reply-To: <Pine.LNX.4.62.0505061846170.5272@numbat.sonytel.be>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050506170923Z8226019-1340+6651@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7890
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips


> This is not the direct `memory map' of the IDE drive's registers! It's an
> indirect map, cfr. e.g.
>
>   #define IDE_DATA_REG            (HWIF(drive)->io_ports[IDE_DATA_OFFSET])
>
> So the actual register is found by looking up offset IDE_DATA_OFFSET in
> the array HWIF(drive)->io_ports[].

Yes, I understand.  This is starting to make more sense.  Here is what I
have figured out:  The first 8 offsets are normally 0-7, just like their
array indexes.  Index 8 and 9, IDE_CONTROLL_OFFSET and IDE_IRQ_OFFSET, were
confusing me because I was expecting them to be the actual offset 8 and 9 --
and I could not find any IDE adapter data sheets that showed them located as
such.  Now that I take a second look at ide_std_init_ports(), I see that the
CONTROL register is treated as a special case, i.e. it is not expected to
follow the STATUS register in address space.  This jives with what I have
seen in data sheets.  

It looks like the example that Alan contributed does not update
HWIF(drive)->io_ports[IDE_IRQ_OFFSET].  Or at least I cant figure out where.
I am having trouble identifying this register in IDE data sheets.  Is it one
of the "not used" or obsolete registers?  Do I need to be conserned with it?
Thanks again.

Bryan



From geert@linux-m68k.org Fri May  6 18:12:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 18:12:52 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:49556 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226019AbVEFRMh>;
	Fri, 6 May 2005 18:12:37 +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 j46HCXUu014693;
	Fri, 6 May 2005 19:12:34 +0200 (MEST)
Date:	Fri, 6 May 2005 19:12:30 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
cc:	"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: ATA devices attached to arbitary busses
In-Reply-To: <200505061709.j46H9L3a021796@nerdnet.nl>
Message-ID: <Pine.LNX.4.62.0505061911220.5272@numbat.sonytel.be>
References: <200505061709.j46H9L3a021796@nerdnet.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7891
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 6 May 2005, Bryan Althouse wrote:
> > This is not the direct `memory map' of the IDE drive's registers! It's an
> > indirect map, cfr. e.g.
> >
> >   #define IDE_DATA_REG            (HWIF(drive)->io_ports[IDE_DATA_OFFSET])
> >
> > So the actual register is found by looking up offset IDE_DATA_OFFSET in
> > the array HWIF(drive)->io_ports[].
> 
> Yes, I understand.  This is starting to make more sense.  Here is what I
> have figured out:  The first 8 offsets are normally 0-7, just like their
> array indexes.  Index 8 and 9, IDE_CONTROLL_OFFSET and IDE_IRQ_OFFSET, were
> confusing me because I was expecting them to be the actual offset 8 and 9 --
> and I could not find any IDE adapter data sheets that showed them located as
> such.  Now that I take a second look at ide_std_init_ports(), I see that the
> CONTROL register is treated as a special case, i.e. it is not expected to
> follow the STATUS register in address space.  This jives with what I have
> seen in data sheets.  
> 
> It looks like the example that Alan contributed does not update
> HWIF(drive)->io_ports[IDE_IRQ_OFFSET].  Or at least I cant figure out where.

Indeed, macide passes 0 for ctrlport and irqport to ide_setup_ports(). If you
need another example, you can look at drivers/ide/legacy/gayle.c.

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 Kiran_Thota@pmc-sierra.com Fri May  6 18:33:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 18:33:40 +0100 (BST)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:23800 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8226009AbVEFRdY>; Fri, 6 May 2005 18:33:24 +0100
Received: (qmail 23887 invoked by uid 101); 6 May 2005 17:33:13 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by mother.pmc-sierra.com with SMTP; 6 May 2005 17:33:13 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j46HXCOi015884;
	Fri, 6 May 2005 10:33:12 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <JGC9C17D>; Fri, 6 May 2005 10:33:12 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F259024380CB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Kiran Thota <Kiran_Thota@pmc-sierra.com>
To:	"'Ulrich Eckhardt'" <eckhardt@satorlaser.com>,
	linux-mips@linux-mips.org
Subject: RE: CF custom implementation
Date:	Fri, 6 May 2005 10:32:40 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Kiran_Thota@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7892
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Kiran_Thota@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

Ulrich,
 The ide-patch i took is from ftp://ftp.buici.com/pub/arm/patch-linux-2.6.11/
Is that good enough?

Alan was referring to PIO mode in that thread but this implementation doesnt 
have IO mode and also no IDE support. It only has memory mode and I will 
have to support it as memory. How do I do that?

Another question: If I rework the board so that the wires coming to MEMR and MEMW
are rewired to IOR and IOW respectively, does it work in TrueIDE mode? Just a thought!


Thanks,
Kiran

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ulrich Eckhardt
Sent: Friday, May 06, 2005 12:14 AM
To: linux-mips@linux-mips.org
Subject: Re: CF custom implementation


Kiran Thota wrote:
> I am working on a MIPS-based processor SoC which has a custom CF
> implementation over Local Bus. The CF doesnt support IO mode, interrupts, 
> 32-bit support.
> It has limited register support [no interface registers to reset the CF]. I
> am using 2.6.10 from linux-mips. I have already written a PCMCIA/CF socket
> socket for the same.
> The goal is to use the CF cards as memoy devices. Advise me on the path to
> take:
>
> PCMCIA/CF ->CS/DS -> IDE [I found a patch to make IDE work in polled mode]

Could you tell me where you found that patch?

> I am currently using Lexar and Hitachi Compact Flash cards.

CF is a standard, so this shouldn't matter.

> The CIS can be read and when the Linux boots up and I invoke cardmgr
> [v3.2.8], it sees the device as ATA/IDE Fixed Disk [Func = 4 (Fixed Disk) ]
> Is there a way to force it to come up in memory only mode? Please suggest.

I'm using a CF card attached to the PCMCIA interface of an Alchemy Au1100. 
Since my board only has a CF slot, I'm not using the whole PCMCIA stack at 
all - CONFIG_PCMCIA=no and no cardmgr. All I do is detect the card, parse the 
CIS and register the CF card with the IDE/ATA system of the kernel, just like 
Alan Cox suggested in the recent thread "ATA devices attached to arbitary 
busses". One good reason for me doing so is that I need to mount the root 
filesystem from the CF but the PCMCIA stack requires user-space helpers.

Uli

From macro@linux-mips.org Fri May  6 18:36:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 18:37:09 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:1541 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226009AbVEFRgy>; Fri, 6 May 2005 18:36:54 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id B937CF59E4; Fri,  6 May 2005 19:36:46 +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 28279-10; Fri,  6 May 2005 19:36:46 +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 D5659E1C6D; Fri,  6 May 2005 19:36:45 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id j46HajwP021329;
	Fri, 6 May 2005 19:36:46 +0200
Date:	Fri, 6 May 2005 18:36:56 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Geert Uytterhoeven <geert@linux-m68k.org>
Cc:	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: ATA devices attached to arbitary busses
In-Reply-To: <Pine.LNX.4.62.0505061911220.5272@numbat.sonytel.be>
Message-ID: <Pine.LNX.4.61L.0505061832390.25293@blysk.ds.pg.gda.pl>
References: <200505061709.j46H9L3a021796@nerdnet.nl>
 <Pine.LNX.4.62.0505061911220.5272@numbat.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/871/Thu May  5 15:50:45 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7893
X-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, 6 May 2005, Geert Uytterhoeven wrote:

> > It looks like the example that Alan contributed does not update
> > HWIF(drive)->io_ports[IDE_IRQ_OFFSET].  Or at least I cant figure out where.
> 
> Indeed, macide passes 0 for ctrlport and irqport to ide_setup_ports(). If you
> need another example, you can look at drivers/ide/legacy/gayle.c.

 Or perhaps at "drivers/ide/mips/swarm.c" which is nice, being for MIPS, 
memory-mapped and wired to an "arbitary bus". ;-)  No DMA, though.

  Maciej

From macro@linux-mips.org Fri May  6 19:41:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 19:42:01 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:10502 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226020AbVEFSlp>; Fri, 6 May 2005 19:41:45 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C34E6F5A3F
	for <linux-mips@linux-mips.org>; Fri,  6 May 2005 20:41:37 +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 15876-07 for <linux-mips@linux-mips.org>;
 Fri,  6 May 2005 20:41:37 +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 27A70F5A1D
	for <linux-mips@linux-mips.org>; Fri,  6 May 2005 20:41:37 +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.1/8.13.1) with ESMTP id j46IfguV024349
	for <linux-mips@linux-mips.org>; Fri, 6 May 2005 20:41:42 +0200
Date:	Fri, 6 May 2005 19:41:53 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <Pine.LNX.4.61L.0505061540540.25293@blysk.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.61L.0505061940470.25293@blysk.ds.pg.gda.pl>
References: <20050506143118Z8225421-1340+6642@linux-mips.org>
 <Pine.LNX.4.61L.0505061540540.25293@blysk.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/871/Thu May  5 15:50:45 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7894
X-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, 6 May 2005, Maciej W. Rozycki wrote:

>  Instead of polluting all the cpu_probe_*() functions, it should actually 
> be moved to decode_config0().  I can apply a suitable fix.

 How about this?

  Maciej

patch-mips-2.6.12-rc3-20050506-4ktlb-0
Index: arch/mips/kernel/cpu-probe.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/cpu-probe.c,v
retrieving revision 1.46
diff -u -p -r1.46 cpu-probe.c
--- arch/mips/kernel/cpu-probe.c	6 May 2005 14:31:13 -0000	1.46
+++ arch/mips/kernel/cpu-probe.c	6 May 2005 18:10:01 -0000
@@ -429,7 +429,7 @@ static inline unsigned int decode_config
 	config0 = read_c0_config();
 
 	if (((config0 & MIPS_CONF_MT) >> 7) == 1)
-		c->options |= MIPS_CPU_TLB;
+		c->options |= MIPS_CPU_TLB | MIPS_CPU_4KTLB;
 	isa = (config0 & MIPS_CONF_AT) >> 13;
 	switch (isa) {
 	case 0:
@@ -515,7 +515,6 @@ static inline void decode_configs(struct
 static inline void cpu_probe_mips(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_4KC:
 		c->cputype = CPU_4KC;
@@ -549,7 +548,6 @@ static inline void cpu_probe_mips(struct
 static inline void cpu_probe_alchemy(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_AU1_REV1:
 	case PRID_IMP_AU1_REV2:
@@ -580,7 +578,6 @@ static inline void cpu_probe_alchemy(str
 static inline void cpu_probe_sibyte(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_SB1:
 		c->cputype = CPU_SB1;
@@ -595,7 +592,6 @@ static inline void cpu_probe_sibyte(stru
 static inline void cpu_probe_sandcraft(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_SR71000:
 		c->cputype = CPU_SR71000;

From bryan.althouse@3phoenix.com Fri May  6 20:57:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 May 2005 20:57:32 +0100 (BST)
Received: from rwcrmhc14.comcast.net ([IPv6:::ffff:216.148.227.89]:56814 "EHLO
	rwcrmhc14.comcast.net") by linux-mips.org with ESMTP
	id <S8226031AbVEFT5P>; Fri, 6 May 2005 20:57:15 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc14) with SMTP
          id <200505061957070140087urue>; Fri, 6 May 2005 19:57:07 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: ATA devices attached to arbitary busses
Date:	Fri, 6 May 2005 15:57:01 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVSYjUJGmHm0bXVS0GMLNJCA4j1uQAEnHfQ
In-Reply-To: <Pine.LNX.4.61L.0505061832390.25293@blysk.ds.pg.gda.pl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050506195715Z8226031-1340+6653@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips

I just read Documents/ide.txt.  It looks like you can tell the kernel where
to find an IDE drive by providing a command line argument
"hdx=cyl,head,sect".  If this is true, I don't see why I would need to write
any kernel code (provided that I design my FPGA local bus IDE host adapter
so that it conforms to the standard).

Bryan



From bvacaliuc@ngit.com Sat May  7 14:08:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 May 2005 14:09:07 +0100 (BST)
Received: from money.ngit.com ([IPv6:::ffff:207.22.44.49]:20148 "EHLO
	money.ngit.com") by linux-mips.org with ESMTP id <S8226091AbVEGNIv> convert rfc822-to-8bit;
	Sat, 7 May 2005 14:08:51 +0100
Received: from lithium (router.ngit.com [207.22.44.62])
	by money.ngit.com (8.11.7p1+Sun/8.11.7) with ESMTP id j47DB2A06638;
	Sat, 7 May 2005 09:11:02 -0400 (EDT)
From:	"Bogdan Vacaliuc" <bvacaliuc@ngit.com>
To:	<ppopov@embeddedalley.com>,
	"'Ruslan V.Pisarev'" <jerry@izmiran.rssi.ru>
Cc:	<linux-mips@linux-mips.org>
Subject: RE: dbau1200 ethernet driver?
Date:	Sat, 7 May 2005 09:08:36 -0400
Organization: NGI Technology, LLC
Message-ID: <00c801c55305$e3de3660$0b03a8c0@lithium>
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
In-Reply-To: <1115394400.5785.3.camel@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Return-Path: <bvacaliuc@ngit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7896
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bvacaliuc@ngit.com
Precedence: bulk
X-list: linux-mips

On Friday, May 06, 2005 11:47 AM, Pete Popov wrote:

> On Fri, 2005-05-06 at 15:53 +0300, Ruslan V.Pisarev wrote:
>>   Hi!
>> 
>>  I compiled last 2.6 kernel (2-3 weeks ago from cvs@linux-mips) and
>> trying to start it on DBAu1200 development board. First problem I
>> discovered with "nfsroot" configuration - is that kernel cannot find
>> network interface at boot-time.  There is a smc91c111 network chip on
>> board, so my question is - what driver is suitable with him?
> 
> The smc91x.c driver. However, I don't remember if that driver was
> tested.  The board was tested with a different smc driver which I
> couldn't push in the tree because it was old and would conflict with
> the smc91x.c.   
> 
>>  Is it "MIPS AU1000 Ethernet support"
>> which fails to compile with "error: `NUM_ETH_INTERFACES' undeclared"
>> (and it must be?) or something different? It seems that I have
>> enabled all other options for ethernet functionality.
> 
> Well, that's a different driver.

Yes, and not for Au1200.  The Au1200 does not have an integrated MAC; access to the MAC/PHY is through the static memory controller.

-bogdan


From bvacaliuc@ngit.com Sat May  7 14:51:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 May 2005 14:51:59 +0100 (BST)
Received: from money.ngit.com ([IPv6:::ffff:207.22.44.49]:23476 "EHLO
	money.ngit.com") by linux-mips.org with ESMTP id <S8226090AbVEGNvo> convert rfc822-to-8bit;
	Sat, 7 May 2005 14:51:44 +0100
Received: from lithium (router.ngit.com [207.22.44.62])
	by money.ngit.com (8.11.7p1+Sun/8.11.7) with ESMTP id j47DrrA06721;
	Sat, 7 May 2005 09:53:57 -0400 (EDT)
From:	"Bogdan Vacaliuc" <bvacaliuc@ngit.com>
To:	"'Kiran Thota'" <Kiran_Thota@pmc-sierra.com>,
	"'Ulrich Eckhardt'" <eckhardt@satorlaser.com>,
	<linux-mips@linux-mips.org>
Subject: RE: CF custom implementation
Date:	Sat, 7 May 2005 09:51:30 -0400
Organization: NGI Technology, LLC
Message-ID: <00c901c5530b$e49542a0$0b03a8c0@lithium>
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
In-Reply-To: <9DFF23E1E33391449FDC324526D1F259024380CB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Return-Path: <bvacaliuc@ngit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7897
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bvacaliuc@ngit.com
Precedence: bulk
X-list: linux-mips

On Friday, May 06, 2005 1:33 PM, Kiran Thota wrote:

> Another question: If I rework the board so that the wires coming to
> MEMR and MEMW are rewired to IOR and IOW respectively, does it work
> in TrueIDE mode? Just a thought!  

No.  TrueIDE mode changes the meaning of many input/output pins, and thus is significantly different from PCcard IO mode so that
this will not work.

Also, you should bear in mind that (P)IO mode is more similar to IDE mode than it is to memory mode.

To operate the CF/CF+ card in memory mapped mode you will need the following signals:

A[0:10]
D[0:15]
-CD1, -CD2
-CE1, -CE2
-OE
RDY_BUSY
-REG
RESET
-WE
WP

Refer to the "CF+ & CF SPECIFICATION REV. 3.0", pg. 24-30 for details.
http://www.compactflash.org/cfspc3_0.pdf

If your cards are not going to be removable, you can get away with tying up/dn some lines.

Also, please note that on pg. 89, the specification allows for alternate ways that a CF card may 'enter' either trueIDE or memory/io
mode.  Please be aware of this, because certain software implementations may inadvertently cause -OE to stay asserted for an
extended period of time, thus causing the card to spontaneously switch modes.  This results in the card seemingly becoming opaque
until the next reset or power cycle.


Best Regards,

-bogdan


From yuasa@hh.iij4u.or.jp Sun May  8 15:34:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 May 2005 15:34:28 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:8941 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224982AbVEHOeJ>;
	Sun, 8 May 2005 15:34:09 +0100
Received: MO(mo01)id j48EXmeF013139; Sun, 8 May 2005 23:33:48 +0900 (JST)
Received: MDO(mdo01) id j48EXlOc028976; Sun, 8 May 2005 23:33:47 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j48EXkgs021753
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Sun, 8 May 2005 23:33:46 +0900 (JST)
Date:	Sun, 8 May 2005 23:33:43 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove obsolete serial setup
Message-Id: <20050508233343.211ae78f.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7898
X-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,

This patch had removed obsolete serial setup for vr41xx.
New vr41xx serial driver is included in 2.6.12-rc3.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff b-orig/arch/mips/vr41xx/casio-e55/setup.c b/arch/mips/vr41xx/casio-e55/setup.c
--- b-orig/arch/mips/vr41xx/casio-e55/setup.c	Thu Apr 29 10:42:48 2004
+++ b/arch/mips/vr41xx/casio-e55/setup.c	Sat Apr 23 10:10:19 2005
@@ -1,7 +1,7 @@
 /*
  *  setup.c, Setup for the CASIO CASSIOPEIA E-11/15/55/65.
  *
- *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2002-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -17,7 +17,6 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include <linux/config.h>
 #include <linux/ioport.h>
 
 #include <asm/io.h>
@@ -33,11 +32,6 @@
 	set_io_port_base(IO_PORT_BASE);
 	ioport_resource.start = IO_PORT_RESOURCE_START;
 	ioport_resource.end = IO_PORT_RESOURCE_END;
-
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-#endif
 
 	return 0;
 }
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/common/Makefile b/arch/mips/vr41xx/common/Makefile
--- b-orig/arch/mips/vr41xx/common/Makefile	Sat Apr 23 09:27:25 2005
+++ b/arch/mips/vr41xx/common/Makefile	Sat Apr 23 09:27:46 2005
@@ -4,7 +4,6 @@
 
 obj-y				+= bcu.o cmu.o icu.o init.o int-handler.o pmu.o
 obj-$(CONFIG_GPIO_VR41XX)	+= giu.o
-obj-$(CONFIG_SERIAL_8250)	+= serial.o
 obj-$(CONFIG_VRC4171)		+= vrc4171.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
 
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/common/serial.c b/arch/mips/vr41xx/common/serial.c
--- b-orig/arch/mips/vr41xx/common/serial.c	Sat Jul 31 20:50:26 2004
+++ b/arch/mips/vr41xx/common/serial.c	Thu Jan  1 09:00:00 1970
@@ -1,178 +0,0 @@
-/*
- *  serial.c, Serial Interface Unit routines for NEC VR4100 series.
- *
- *  Copyright (C) 2002  MontaVista Software Inc.
- *    Author: Yoichi Yuasa <yyuasa@mvista.com or source@mvista.com>
- *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-/*
- * Changes:
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4122 and VR4131 are supported.
- *  - Added support for NEC VR4111 and VR4121.
- *
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *  - Added support for NEC VR4133.
- */
-#include <linux/init.h>
-#include <linux/types.h>
-#include <linux/tty.h>
-#include <linux/serial.h>
-#include <linux/serial_core.h>
-#include <linux/smp.h>
-
-#include <asm/addrspace.h>
-#include <asm/cpu.h>
-#include <asm/io.h>
-#include <asm/vr41xx/vr41xx.h>
-
-#define SIUIRSEL_TYPE1		KSEG1ADDR(0x0c000008)
-#define SIUIRSEL_TYPE2		KSEG1ADDR(0x0f000808)
- #define USE_RS232C		0x00
- #define USE_IRDA		0x01
- #define SIU_USES_IRDA		0x00
- #define FIR_USES_IRDA		0x02
- #define IRDA_MODULE_SHARP	0x00
- #define IRDA_MODULE_TEMIC	0x04
- #define IRDA_MODULE_HP		0x08
- #define TMICTX			0x10
- #define TMICMODE		0x20
-
-#define SIU_BASE_TYPE1		0x0c000000UL	/* VR4111 and VR4121 */
-#define SIU_BASE_TYPE2		0x0f000800UL	/* VR4122, VR4131 and VR4133 */
-#define SIU_SIZE		0x8UL
-
-#define SIU_BASE_BAUD		1152000
-
-/* VR4122, VR4131 and VR4133 DSIU Registers */
-#define DSIU_BASE		0x0f000820UL
-#define DSIU_SIZE		0x8UL
-
-#define DSIU_BASE_BAUD		1152000
-
-int vr41xx_serial_ports = 0;
-
-void vr41xx_select_siu_interface(siu_interface_t interface,
-                                 irda_module_t module)
-{
-	uint16_t val = USE_RS232C;	/* Select RS-232C */
-
-	/* Select IrDA */
-	if (interface == SIU_IRDA) {
-		switch (module) {
-		case IRDA_SHARP:
-			val = IRDA_MODULE_SHARP;
-			break;
-		case IRDA_TEMIC:
-			val = IRDA_MODULE_TEMIC;
-			break;
-		case IRDA_HP:
-			val = IRDA_MODULE_HP;
-			break;
-		default:
-			printk(KERN_ERR "SIU: unknown IrDA module\n");
-			return;
-		}
-		val |= USE_IRDA | SIU_USES_IRDA;
-	}
-
-	switch (current_cpu_data.cputype) {
-	case CPU_VR4111:
-	case CPU_VR4121:
-		writew(val, SIUIRSEL_TYPE1);
-		break;
-	case CPU_VR4122:
-	case CPU_VR4131:
-	case CPU_VR4133:
-		writew(val, SIUIRSEL_TYPE2);
-		break;
-	default:
-		printk(KERN_ERR "SIU: unsupported CPU of NEC VR4100 series\n");
-		break;
-	}
-}
-
-void __init vr41xx_siu_init(void)
-{
-	struct uart_port port;
-
-	memset(&port, 0, sizeof(port));
-
-	port.line = vr41xx_serial_ports;
-	port.uartclk = SIU_BASE_BAUD * 16;
-	port.irq = SIU_IRQ;
-	port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
-	switch (current_cpu_data.cputype) {
-	case CPU_VR4111:
-	case CPU_VR4121:
-		port.mapbase = SIU_BASE_TYPE1;
-		break;
-	case CPU_VR4122:
-	case CPU_VR4131:
-	case CPU_VR4133:
-		port.mapbase = SIU_BASE_TYPE2;
-		break;
-	default:
-		printk(KERN_ERR "SIU: unsupported CPU of NEC VR4100 series\n");
-		return;
-	}
-	port.regshift = 0;
-	port.iotype = UPIO_MEM;
-	port.membase = ioremap(port.mapbase, SIU_SIZE);
-	if (port.membase != NULL) {
-		if (early_serial_setup(&port) == 0) {
-			vr41xx_supply_clock(SIU_CLOCK);
-			vr41xx_serial_ports++;
-			return;
-		}
-	}
-
-	printk(KERN_ERR "SIU: setup failed!\n");
-}
-
-void __init vr41xx_dsiu_init(void)
-{
-	struct uart_port port;
-
-	if (current_cpu_data.cputype != CPU_VR4122 &&
-	    current_cpu_data.cputype != CPU_VR4131 &&
-	    current_cpu_data.cputype != CPU_VR4133) {
-		printk(KERN_ERR "DSIU: unsupported CPU of NEC VR4100 series\n");
-		return;
-	}
-
-	memset(&port, 0, sizeof(port));
-
-	port.line = vr41xx_serial_ports;
-	port.uartclk = DSIU_BASE_BAUD * 16;
-	port.irq = DSIU_IRQ;
-	port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
-	port.mapbase = DSIU_BASE;
-	port.regshift = 0;
-	port.iotype = UPIO_MEM;
-	port.membase = ioremap(port.mapbase, DSIU_SIZE);
-	if (port.membase != NULL) {
-		if (early_serial_setup(&port) == 0) {
-			vr41xx_supply_clock(DSIU_CLOCK);
-			vr41xx_enable_dsiuint(DSIUINT_ALL);
-			vr41xx_serial_ports++;
-			return;
-		}
-	}
-
-	printk(KERN_ERR "DSIU: setup failed!\n");
-}
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/ibm-workpad/setup.c b/arch/mips/vr41xx/ibm-workpad/setup.c
--- b-orig/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Apr 29 10:42:48 2004
+++ b/arch/mips/vr41xx/ibm-workpad/setup.c	Sat Apr 23 10:11:07 2005
@@ -1,7 +1,7 @@
 /*
  *  setup.c, Setup for the IBM WorkPad z50.
  *
- *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2002-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -17,7 +17,6 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include <linux/config.h>
 #include <linux/ioport.h>
 
 #include <asm/io.h>
@@ -33,11 +32,6 @@
 	set_io_port_base(IO_PORT_BASE);
 	ioport_resource.start = IO_PORT_RESOURCE_START;
 	ioport_resource.end = IO_PORT_RESOURCE_END;
-
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-#endif
 
 	return 0;
 }
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/nec-cmbvr4133/setup.c b/arch/mips/vr41xx/nec-cmbvr4133/setup.c
--- b-orig/arch/mips/vr41xx/nec-cmbvr4133/setup.c	Wed Dec 15 23:08:18 2004
+++ b/arch/mips/vr41xx/nec-cmbvr4133/setup.c	Sat Apr 23 10:12:23 2005
@@ -55,15 +55,6 @@
 #define number_partitions (sizeof(cmbvr4133_mtd_parts)/sizeof(struct mtd_partition))
 #endif
 
-extern void (*late_time_init)(void);
-
-static void __init vr4133_serial_init(void)
-{
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-	vr41xx_dsiu_init();
-}
-
 extern void i8259_init(void);
 
 static int __init nec_cmbvr4133_setup(void)
@@ -77,8 +68,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_NEC_CMBVR4133;
-
-	late_time_init = vr4133_serial_init;
 
 #ifdef CONFIG_PCI
 #ifdef CONFIG_ROCKHOPPER
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c b/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- b-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu May 27 08:14:29 2004
+++ b/arch/mips/vr41xx/tanbac-tb0226/setup.c	Sat Apr 23 10:13:27 2005
@@ -1,7 +1,7 @@
 /*
  *  setup.c, Setup for the TANBAC TB0226.
  *
- *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2002-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -17,23 +17,8 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include <linux/config.h>
-
-#include <asm/vr41xx/vr41xx.h>
 
 const char *get_system_type(void)
 {
 	return "TANBAC TB0226";
 }
-
-static int tanbac_tb0226_setup(void)
-{
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-#endif
-
-	return 0;
-}
-
-early_initcall(tanbac_tb0226_setup);
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c b/arch/mips/vr41xx/tanbac-tb0229/setup.c
--- b-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c	Thu May 27 08:14:29 2004
+++ b/arch/mips/vr41xx/tanbac-tb0229/setup.c	Sat Apr 23 10:14:05 2005
@@ -1,7 +1,7 @@
 /*
  *  setup.c, Setup for the TANBAC TB0229 (VR4131DIMM)
  *
- *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2002-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  Modified for TANBAC TB0229:
  *  Copyright (C) 2003  Megasolution Inc.  <matsu@megasolution.jp>
@@ -20,24 +20,8 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include <linux/config.h>
-
-#include <asm/vr41xx/vr41xx.h>
 
 const char *get_system_type(void)
 {
 	return "TANBAC TB0229";
 }
-
-static int tanbac_tb0229_setup(void)
-{
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-	vr41xx_dsiu_init();
-#endif
-
-	return 0;
-}
-
-early_initcall(tanbac_tb0229_setup);
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/victor-mpc30x/setup.c b/arch/mips/vr41xx/victor-mpc30x/setup.c
--- b-orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu May 27 08:14:29 2004
+++ b/arch/mips/vr41xx/victor-mpc30x/setup.c	Sat Apr 23 10:14:29 2005
@@ -1,7 +1,7 @@
 /*
  *  setup.c, Setup for the Victor MP-C303/304.
  *
- *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2002-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -17,23 +17,8 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include <linux/config.h>
-
-#include <asm/vr41xx/vr41xx.h>
 
 const char *get_system_type(void)
 {
 	return "Victor MP-C303/304";
 }
-
-static int victor_mpc30x_setup(void)
-{
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-#endif
-
-	return 0;
-}
-
-early_initcall(victor_mpc30x_setup);
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/zao-capcella/setup.c b/arch/mips/vr41xx/zao-capcella/setup.c
--- b-orig/arch/mips/vr41xx/zao-capcella/setup.c	Thu May 27 08:14:29 2004
+++ b/arch/mips/vr41xx/zao-capcella/setup.c	Sat Apr 23 10:15:17 2005
@@ -1,7 +1,7 @@
 /*
  *  setup.c, Setup for the ZAO Networks Capcella.
  *
- *  Copyright (C) 2002-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2002-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -17,24 +17,8 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include <linux/config.h>
-
-#include <asm/vr41xx/vr41xx.h>
 
 const char *get_system_type(void)
 {
 	return "ZAO Networks Capcella";
 }
-
-static int zao_capcella_setup(void)
-{
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-	vr41xx_dsiu_init();
-#endif
-
-	return 0;
-}
-
-early_initcall(zao_capcella_setup);
diff -urN -X dontdiff b-orig/include/asm-mips/vr41xx/vr41xx.h b/include/asm-mips/vr41xx/vr41xx.h
--- b-orig/include/asm-mips/vr41xx/vr41xx.h	Sat Apr 23 09:27:25 2005
+++ b/include/asm-mips/vr41xx/vr41xx.h	Sat Apr 23 10:15:50 2005
@@ -231,32 +231,4 @@
 	DATA_HIGH
 };
 
-/*
- * Serial Interface Unit
- */
-extern void vr41xx_siu_init(void);
-extern int vr41xx_serial_ports;
-
-/* SIU interfaces */
-typedef enum {
-	SIU_RS232C,
-	SIU_IRDA
-} siu_interface_t;
-
-/* IrDA interfaces */
-typedef enum {
-	IRDA_NONE,
-	IRDA_SHARP,
-	IRDA_TEMIC,
-	IRDA_HP
-} irda_module_t;
-
-extern void vr41xx_select_siu_interface(siu_interface_t interface,
-                                        irda_module_t module);
-
-/*
- * Debug Serial Interface Unit
- */
-extern void vr41xx_dsiu_init(void);
-
 #endif /* __NEC_VR41XX_H */


From anemo@mba.ocn.ne.jp Tue May 10 04:11:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 May 2005 04:11:33 +0100 (BST)
Received: from [IPv6:::ffff:202.230.225.5] ([IPv6:::ffff:202.230.225.5]:13584
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224786AbVEJDLD>; Tue, 10 May 2005 04:11:03 +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; 10 May 2005 03:10:52 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 726161D703
	for <linux-mips@linux-mips.org>; Tue, 10 May 2005 12:10:39 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 5DEF2183D4
	for <linux-mips@linux-mips.org>; Tue, 10 May 2005 12:10:39 +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 j4A3Acoj083787
	for <linux-mips@linux-mips.org>; Tue, 10 May 2005 12:10:39 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Tue, 10 May 2005 12:10:38 +0900 (JST)
Message-Id: <20050510.121038.111209401.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Subject: fpu, preempt, ptrace
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7899
X-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

Here is a (revised) patch to fix some preempt issues around fpu and ptrace.

For now, get_fpu_regs() is used in ptrace code only and the condition
'tsk == current' should always be false.  So we can just remove
_save_fp() call instead of disabling preemption.

diff -ur linux-mips/arch/mips/kernel/ptrace.c linux/arch/mips/kernel/ptrace.c
--- linux-mips/arch/mips/kernel/ptrace.c	2005-04-18 11:42:47.000000000 +0900
+++ linux/arch/mips/kernel/ptrace.c	2005-05-10 11:41:35.000000000 +0900
@@ -169,10 +169,12 @@
 			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;
 		}
 		default:
diff -ur linux-mips/arch/mips/kernel/ptrace32.c linux/arch/mips/kernel/ptrace32.c
--- linux-mips/arch/mips/kernel/ptrace32.c	2005-04-18 11:42:47.000000000 +0900
+++ linux/arch/mips/kernel/ptrace32.c	2005-05-10 11:38:51.000000000 +0900
@@ -155,10 +155,12 @@
 			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;
 		}
 		default:
diff -ur linux-mips/include/asm-mips/fpu.h linux/include/asm-mips/fpu.h
--- linux-mips/include/asm-mips/fpu.h	2005-05-10 10:21:31.000000000 +0900
+++ linux/include/asm-mips/fpu.h	2005-05-10 11:38:38.000000000 +0900
@@ -132,8 +132,10 @@
 static inline fpureg_t *get_fpu_regs(struct task_struct *tsk)
 {
 	if (cpu_has_fpu) {
+		preempt_disable();
 		if ((tsk == current) && __is_fpu_owner()) 
 			_save_fp(current);
+		preempt_enable();
 		return tsk->thread.fpu.hard.fpr;
 	}
 
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Tue May 10 16:04:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 May 2005 16:04:40 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:53988 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8226704AbVEJPEW>; Tue, 10 May 2005 16:04:22 +0100
Received: from localhost (p6003-ipad11funabasi.chiba.ocn.ne.jp [219.162.41.3])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id B479587AF; Wed, 11 May 2005 00:04:18 +0900 (JST)
Date:	Wed, 11 May 2005 00:06:20 +0900 (JST)
Message-Id: <20050511.000620.25910671.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: Re: fpu, preempt, ptrace
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050510.121038.111209401.nemoto@toshiba-tops.co.jp>
References: <20050510.121038.111209401.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 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: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7901
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Tue, 10 May 2005 12:10:38 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> For now, get_fpu_regs() is used in ptrace code only and the
anemo> condition 'tsk == current' should always be false.  So we can
anemo> just remove _save_fp() call instead of disabling preemption.

The get_fpu_regs() fix was insufficient.  The caller of the function
should disable preemption.  And while the caller (sys_ptrace) never
pass 'current' to the function, it should be preempt-safe anyway.
Please ignore that part of my patch.

---
Atsushi Nemoto

From hjl@lucon.org Wed May 11 01:59:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 May 2005 02:00:05 +0100 (BST)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:62876 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8226762AbVEKA7o>; Wed, 11 May 2005 01:59:44 +0100
Received: from lucon.org ([24.6.212.230]) by comcast.net (rwcrmhc13) with ESMTP
          id <2005051100593401500pge02e>; Wed, 11 May 2005 00:59:35 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 25C88649BC; Tue, 10 May 2005 17:59:34 -0700 (PDT)
Date:	Tue, 10 May 2005 17:59:34 -0700
From:	"H. J. Lu" <hjl@lucon.org>
To:	linux-gcc@vger.kernel.org
Cc:	gcc@gcc.gnu.org, GNU C Library <libc-alpha@sources.redhat.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>
Subject: The Linux binutils 2.16.90.0.3 is released
Message-ID: <20050511005933.GA4103@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <hjl@lucon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7902
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

This is the beta release of binutils 2.16.90.0.3 for Linux, which is
based on binutils 2005 0510 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,

	movl (%eax),%ds
	movl %ds,(%eax)

To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,

	mov (%eax),%ds
	mov %ds,(%eax)

should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.3 will also support

	movw (%eax),%ds
	movw %ds,(%eax)

without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch

The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add

ifeq ($(CONFIG_ITANIUM),y)
	CFLAGS += -Wa,-mtune=itanium1
	AFLAGS += -Wa,-mtune=itanium1
endif

to arch/ia64/Makefile in your kernel source tree.

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

and

http://www.sourceware.org/bugzilla/

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.

Changes from binutils 2.16.90.0.2:

1. Update from binutils 2005 0510.
2. Update ia64 assembler to support comdat group section generated by
gcc 4 (PR 940).
3. Fix a linker crash on bad input (PR 939).
4. Fix a sh64 assembler regression (PR 936).
5. Support linker script on executable (PR 882).
6. Fix the linker -pie regression (PR 878).
7. Fix an x86_64 disassembler bug (PR 843).
8. Fix a PPC linker regression.
9. Misc speed up.

Changes from binutils 2.16.90.0.1:

1. Update from binutils 2005 0429.
2. Fix an ELF linker regression (PR 815).
3. Fix an empty section removal related bug.
4. Fix an ia64 linker regression (PR 855).
5. Don't allow local symbol to be equated common/undefined symbols (PR
857).
6. Fix the ia64 linker to handle local dynamic symbol error reporting.
7. Make non-debugging reference to discarded section an error (PR 858).
8. Support Sparc/TLS.
9. Support rpm build with newer rpm.
10. Fix an alpha linker regression.
11. Fix the non-gcc build regression.

Changes from binutils 2.15.94.0.2.2:

1. Update from binutils 2005 0408.
2. The i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location.
3. The x86_64 assembler now allows movq between a segment register and
a 64bit general purpose register.
4. 20x Speed up linker for input files with >64K sections.
5. Properly report ia64 linker relaxation failures.
6. Support tuning ia64 assembler for Itanium 2 processors.
7. Linker will remove empty unused output sections.
8. Add -N to readelf to display full section names.
9. Fix the ia64 linker to support linkonce text sections without unwind
sections.
10. More unwind directive checkings in the ia64 assembler.
11. Speed up linker with wildcard handling.
12. Fix readelf to properly dump .debug_ranges and .debug_loc sections.

Changes from binutils 2.15.94.0.2:

1. Fix greater than 64K section support in linker.
2. Properly handle i386 and x86_64 protected symbols in linker.
3. Fix readelf for LEB128 on 64bit hosts.
4. Speed up readelf for section group process.
5. Include ia64 texinfo pages.
6. Change ia64 assembler to check hint.b for Montecito.
7. Improve relaxation failure report in ia64 linker.
8. Fix ia64 linker to allow relax backward branch in the same section.

Changes from binutils 2.15.94.0.1:

1. Update from binutils 2004 1220.
2. Fix strip for TLS symbol references.

Changes from binutils 2.15.92.0.2:

1. Update from binutils 2004 1121.
2. Put ia64 .ctors/.dtors sections next to small data section for
Intel ia64 compiler.
3. Fix -Bdynamic/-Bstatic handling for linker script.
4. Provide more information on relocation overflow.
5. Add --sort-section to linker.
6. Support icc 8.1 unwind info in readelf.
7. Fix the infinite loop bug on bad input in the ia64 assembler.
8. Fix ia64 SECREL relocation in linker.
9. Fix a section group memory leak in readelf.

Changes from binutils 2.15.91.0.2:

1. Update from binutils 2004 0927.
2. Work around a section header bug in Intel ia64 compiler.
3. Fix an unwind directive bug in the ia64 assembler.
4. Fix various PPC bugs.
5. Update ARM support.
6. Fix an x86-64 linker warning while building Linux kernel.

Changes from binutils 2.15.91.0.1:

1. Update from binutils 2004 0727.
2. Fix the x86_64 linker to prevent non-PIC code in shared library.
3. Fix the ia64 linker to warn the relotable files which can't be
relaxed.
4. Fix the comdat group support. Allow mix single-member comdat group
with linkonce section.
5. Added --add-needed/--no-add-needed options to linker.
6. Fix the SHF_LINK_ORDER support.
7. Fix the ia64 assembler for multiple sections with the same name and
SHT_IA_64_UNWIND sections.
8. Fix the ia64 assembler for merge section and relaxation.

Changes from binutils 2.15.90.0.3:

1. Update from binutils 2004 0527.
2. Fix -x auto option in the ia64 assembler.
3. Add the AR check in the ia64 assembler.
4. Fix the section group support.
5. Add a new -z relro linker option.
6. Fix an exception section placement bug in linker.
7. Add .serialize.data and .serialize.instruction to the ia64
assembler.

Changes from binutils 2.15.90.0.2:

1. Update from binutils 2004 0415.
2. Fix the linker for weak undefined symbol handling.
3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC
code.

Changes from binutils 2.15.90.0.1.1:

1. Update from binutils 2004 0412.
2. Add --as-needed/--no-as-needed to linker.
3. Fix -z defs in linker.
4. Always reserve the memory for ia64 dynamic linker.
5. Fix a race condition in ia64 lazy binding.

Changes from binutils 2.15.90.0.1:

1. Fixed an ia64 assembler bug.
2. Install the assembler man page.

Changes from binutils 2.14.90.0.8:

1. Update from binutils 2004 0303.
2. Fixed linker for undefined symbols with non-default visibility.
3. Sped up linker weakdef symbol handling.
4. Fixed mixing ELF32 and ELF64 object files in archive.
5. Added ia64 linker brl optimization.
6. Fixed ia64 linker to disallow invalid dynamic relocations.
7. Fixed DT_TEXTREL handling in ia64 linker.
8. Fixed alignment handling in ia64 assembler.
9. Improved ia64 assembler unwind table handling. 

Changes from binutils 2.14.90.0.7:

1. Update from binutils 2004 0114.
2. Fixed an ia64 assembler unwind table bug. 
3. Better handle IPF linker relaxation overflow.
4. Fixed misc PPC bugs.

Changes from binutils 2.14.90.0.6:

1. Update from binutils 2003 1029.
2. Allow type changes for undefined symbols.
3. Fix EH frame optimization.
4. Fix the check for undefined versioned symbol with wildcard.
5. Support generating code for Itanium.
6. Detect and warn bad symbol index.
7. Update IPF assemebler DV check.

Changes from binutils 2.14.90.0.5:

1. Update from binutils 2003 0820.
2. No longer use section names for ELF section types nor flags.
3. Fix some ELF/IA64 linker bugs.
4. Fix some ELF/ppc bugs.
5. Add archive support to readelf.

Changes from binutils 2.14.90.0.4.1:

1. Update from binutils 2003 0722.
2. Fix an ELF/mips linker bug.
3. Fix an ELF/hpppa linker bug.
4. Fix an ELF/ia64 assembler bug.
5. Fix a linkonce support with C++ debug.
6. A new working C++ demangler.
7. Various alpha, mips, ia64, ... bug fixes.
8. Support for the current gcc and glibc.

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel Prescott New Instructions.

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

1. Update from binutils 2003 0523.
2. Fix 2 ELF visibility bugs.
3. Fix ELF/ppc linker bugs.

Changes from binutils 2.14.90.0.1:

1. Update from binutils 2003 0515.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Add more IAS compatibilities to ia64 assembler.

Changes from binutils 2.13.90.0.20:

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

Changes from binutils 2.13.90.0.18:

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

Changes from binutils 2.13.90.0.16:

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

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

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

Changes from binutils 2.13.90.0.10:

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

Changes from binutils 2.13.90.0.4:

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

Changes from binutils 2.13.90.0.3:

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

Changes from binutils 2.13.90.0.2:

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

The file list:

1. binutils-2.16.90.0.3.tar.bz2. Source code.
2. binutils-2.16.90.0.2-2.16.90.0.3.diff.bz2. Patch against the
   previous beta source code.
3. binutils-2.16.90.0.3-1.i386.rpm. IA-32 binary RPM for RedHat EL 3.
4. binutils-2.16.90.0.3-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3.
5. binutils-2.16.90.0.3-1.x86_64.rpm. X64_64 binary RPM for RedHat
   EL 3.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.16.90.0.3.tar.bz2

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
05/11/2005

From eckhardt@satorlaser.com Wed May 11 13:33:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 May 2005 13:33:29 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.176]:27596
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225841AbVEKMdN>; Wed, 11 May 2005 13:33:13 +0100
Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1DVqOk-0007FV-00
	for linux-mips@linux-mips.org; Wed, 11 May 2005 14:33:10 +0200
Received: from [213.39.254.68] (helo=tuxator.satorlaser-intern.com)
	by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128)
	(Exim 3.35 #1)
	id 1DVqOk-00033D-00
	for linux-mips@linux-mips.org; Wed, 11 May 2005 14:33:10 +0200
From:	Ulrich Eckhardt <eckhardt@satorlaser.com>
Organization: Sator Laser GmbH
To:	linux-mips@linux-mips.org
Subject: CompactFlash/ATA on Au1100 misses interrupts
Date:	Wed, 11 May 2005 14:34:39 +0200
User-Agent: KMail/1.7.2
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505111434.39601.eckhardt@satorlaser.com>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae
Return-Path: <eckhardt@satorlaser.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7903
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eckhardt@satorlaser.com
Precedence: bulk
X-list: linux-mips

Hi!

I'm trying to glue together my board (TTP1100, almost like DB1100) with a 
compact flash card and I'm already pretty far, but the interrupt-controlled 
ATA driver still doesn't work. 

The problem seems to be that the CF generates such short pulses on the IREQ 
line that they are simply missed. However, some facts first:
1. If I configure the connected GPIO for edge sensitivity (rising or falling 
doesn't matter) and issue an ATA command to the CF, I see the interrupt.
2. If I configure for level sensitivity and issue ATA commands, I see no 
interrupts. Using a logic analyzer, I saw that the generated impulses are 
~600ns long, which is not too short usually.
3. If I remove the CF card, configure for level sensitivity and pull the pin 
to ground, I see an interrupt.

I'm currently a bit out of ideas what to try, if any of you have another idea 
where I could look I'm open for it.

Another thing I was wondering about is the boot message that it's "Assuming 
50MHz system bus speed". Can/should I specify this differently?

thanks

Uli

From alan@lxorguk.ukuu.org.uk Wed May 11 15:06:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 May 2005 15:06:21 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:42683
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225847AbVEKOGG>; Wed, 11 May 2005 15:06:06 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j4BE4fEj010515;
	Wed, 11 May 2005 15:04:41 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j4BE4dxn010514;
	Wed, 11 May 2005 15:04:40 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: CompactFlash/ATA on Au1100 misses interrupts
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Ulrich Eckhardt <eckhardt@satorlaser.com>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <200505111434.39601.eckhardt@satorlaser.com>
References: <200505111434.39601.eckhardt@satorlaser.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1115820274.26693.246.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Wed, 11 May 2005 15:04:35 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7904
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Mer, 2005-05-11 at 13:34, Ulrich Eckhardt wrote:
> Another thing I was wondering about is the boot message that it's "Assuming 
> 50MHz system bus speed". Can/should I specify this differently?

That is only used for a few obscure old controllers so should be
irrelevant. 

From mile.davidovic@micronasnit.com Wed May 11 15:20:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 May 2005 15:20:57 +0100 (BST)
Received: from krt.tmd.ns.ac.yu ([IPv6:::ffff:147.91.177.65]:47845 "EHLO
	krt.neobee.net") by linux-mips.org with ESMTP id <S8225941AbVEKOUm>;
	Wed, 11 May 2005 15:20:42 +0100
Received: from localhost (localhost [127.0.0.1])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4BEP6ZF017571
	for <linux-mips@linux-mips.org>; Wed, 11 May 2005 16:25:07 +0200
Received: from krt.neobee.net ([127.0.0.1])
 by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 17140-04 for <linux-mips@linux-mips.org>;
 Wed, 11 May 2005 16:25:06 +0200 (CEST)
Received: from davidovic ([192.168.0.89])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4BEOu1p017560
	for <linux-mips@linux-mips.org>; Wed, 11 May 2005 16:24:56 +0200
Message-Id: <200505111424.j4BEOu1p017560@krt.neobee.net>
Reply-To: <mile.davidovic@micronasnit.com>
From:	"Mile Davidovic" <mile.davidovic@micronasnit.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Mips 4KEC
Date:	Wed, 11 May 2005 16:20:53 +0200
Organization: MicronasNIT
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcVWNKOCiTGfbgnLQ5CxCzsEl5x71g==
X-Virus-Scanned: by amavisd-new at krt.neobee.net
Return-Path: <mile.davidovic@micronasnit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7905
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mile.davidovic@micronasnit.com
Precedence: bulk
X-list: linux-mips

Hello all

I tried to port linux 2.6.11-mipscvs-20050313 on MIPS 4KEC processor.

But I faced with some problems.

1. I have question regarding toolchain, I use toolchain which came from
uclibc buildroot
application. Gcc version is 3.4.2, is it ok?

2. I tried to use sde-lite 5.03 toolchain but this toolchain (sde-gcc)
failed to build kernel. 
    Please any comments regarding this issue? 

3. I tried to remove optimization from kernel: 
		ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
		CFLAGS		+= -Os
		else
		#CFLAGS		+= -O2
		endif
but kernel failed to compile with next messages:
	init/built-in.o(.init.text+0x216c): In function
`identify_ramdisk_image':
	init/do_mounts_rd.c:92: undefined reference to `ntohl'
	kernel/built-in.o(.text+0xf6f4): In function `put_files_struct':
	include/asm/system.h:270: undefined reference to
`__xchg_u64_unsupported_on_32bit_kernels'
	kernel/built-in.o(.text+0xf708):include/asm/system.h:273: undefined
reference to `__xchg_called_with_bad_pointer'
	kernel/built-in.o(.text+0x13264): In function `wait_task_zombie':
	include/asm/system.h:270: undefined reference to
`__xchg_u64_unsupported_on_32bit_kernels'
	kernel/built-in.o(.text+0x13278):include/asm/system.h:273: undefined
reference to `__xchg_called_with_bad_pointer'
	....
I tried with googling but it seems that nobody faced similar problem? Is it
possible to buidl kernel without optimization?

Best regards Mile


From ralf@linux-mips.org Wed May 11 15:27:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 May 2005 15:27:33 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:8729 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225941AbVEKO1S>; Wed, 11 May 2005 15:27:18 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4BERCRH017168;
	Wed, 11 May 2005 15:27:12 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4BER7X9017167;
	Wed, 11 May 2005 15:27:07 +0100
Date:	Wed, 11 May 2005 15:27:07 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Mile Davidovic <mile.davidovic@micronasnit.com>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Mips 4KEC
Message-ID: <20050511142707.GF6072@linux-mips.org>
References: <200505111424.j4BEOu1p017560@krt.neobee.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200505111424.j4BEOu1p017560@krt.neobee.net>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7906
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, May 11, 2005 at 04:20:53PM +0200, Mile Davidovic wrote:

> 1. I have question regarding toolchain, I use toolchain which came from
> uclibc buildroot
> application. Gcc version is 3.4.2, is it ok?

Yes.

> 2. I tried to use sde-lite 5.03 toolchain but this toolchain (sde-gcc)
> failed to build kernel. 
>     Please any comments regarding this issue? 

> 3. I tried to remove optimization from kernel: 

> I tried with googling but it seems that nobody faced similar problem? Is it
> possible to buidl kernel without optimization?

No.  That's FAQ since 10 years.

  Ralf

From nigel@mips.com Wed May 11 17:13:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 May 2005 17:13:59 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:3343 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8226018AbVEKQNl>;
	Wed, 11 May 2005 17:13:41 +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 1DVu93-0006LG-00; Wed, 11 May 2005 17:33:13 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=shoreditch.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1DVtpW-0004Uk-00; Wed, 11 May 2005 17:13:02 +0100
Received: from 127.0.0.1 (ident=unknown) by shoreditch.mips.com with
 esmtp (masqmail 0.2.20) id 1DVtpW-5nX-00; Wed, 11 May 2005 17:13:02
 +0100
Message-ID: <42822F0D.4030602@mips.com>
Date:	Wed, 11 May 2005 17:13:01 +0100
From:	Nigel Stephens <nigel@mips.com>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	mile.davidovic@micronasnit.com
CC:	'Linux/MIPS Development' <linux-mips@linux-mips.org>
Subject: Re: Mips 4KEC
References: <200505111424.j4BEOu1p017560@krt.neobee.net>
In-Reply-To: <200505111424.j4BEOu1p017560@krt.neobee.net>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.824,
	required 4, AWL, BAYES_00)
Return-Path: <nigel@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7907
X-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

Mile Davidovic wrote:

>
>
>2. I tried to use sde-lite 5.03 toolchain but this toolchain (sde-gcc)
>failed to build kernel. 
>    Please any comments regarding this issue? 
>

SDE-lite is a "bare-iron" compiler which isn't very suitable for 
building the Linux kernel. Instead you could try the version of the SDE 
toolchain which has been configured as a Linux compiler, as described 
here http://www.linux-mips.org/wiki/index.php/Toolchains#MIPS_SDE

Nigel

From yuasa@hh.iij4u.or.jp Fri May 13 14:25:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2005 14:25:52 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:20727 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225742AbVEMNZg>;
	Fri, 13 May 2005 14:25:36 +0100
Received: MO(mo01)id j4DDPVqj002124; Fri, 13 May 2005 22:25:31 +0900 (JST)
Received: MDO(mdo01) id j4DDPUg7027263; Fri, 13 May 2005 22:25:30 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j4DDPTir001801
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Fri, 13 May 2005 22:25:30 +0900 (JST)
Date:	Fri, 13 May 2005 22:25:28 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove old TB0219 driver
Message-Id: <20050513222528.010b2a4d.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7910
X-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,

This patch had removed old TB0219 driver.
Please apply.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff b-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile b/arch/mips/vr41xx/tanbac-tb0229/Makefile
--- b-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile	Thu Apr 29 10:42:49 2004
+++ b/arch/mips/vr41xx/tanbac-tb0229/Makefile	Sun Apr 24 00:18:11 2005
@@ -3,5 +3,3 @@
 #
 
 obj-y				:= setup.o
-
-obj-$(CONFIG_TANBAC_TB0219)	+= tb0219.o
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c b/arch/mips/vr41xx/tanbac-tb0229/tb0219.c
--- b-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c	Thu May 27 08:14:29 2004
+++ b/arch/mips/vr41xx/tanbac-tb0229/tb0219.c	Thu Jan  1 09:00:00 1970
@@ -1,44 +0,0 @@
-/*
- *  tb0219.c, Setup for the TANBAC TB0219
- *
- *  Copyright (C) 2003  Megasolution Inc. <matsu@megasolution.jp>
- *  Copyright (C) 2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#include <linux/init.h>
-
-#include <asm/io.h>
-#include <asm/reboot.h>
-
-#define TB0219_RESET_REGS	KSEG1ADDR(0x0a00000e)
-
-#define tb0219_hard_reset()	writew(0, TB0219_RESET_REGS)
-
-static void tanbac_tb0219_restart(char *command)
-{
-	local_irq_disable();
-	tb0219_hard_reset();
-	while (1);
-}
-
-static int __init tanbac_tb0219_setup(void)
-{
-	_machine_restart = tanbac_tb0219_restart;
-
-	return 0;
-}
-
-early_initcall(tanbac_tb0219_setup);



From yuasa@hh.iij4u.or.jp Fri May 13 14:26:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2005 14:27:16 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:41207 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225748AbVEMN07>;
	Fri, 13 May 2005 14:26:59 +0100
Received: MO(mo01)id j4DDQuiG002344; Fri, 13 May 2005 22:26:56 +0900 (JST)
Received: MDO(mdo01) id j4DDQtUa027289; Fri, 13 May 2005 22:26:55 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j4DDQsp1001952
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Fri, 13 May 2005 22:26:54 +0900 (JST)
Date:	Fri, 13 May 2005 22:26:53 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove old vrc4171 driver
Message-Id: <20050513222653.7828e1fd.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7911
X-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,

This patch had removed old vrc4171 driver.
Please apply.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff b-orig/arch/mips/vr41xx/common/Makefile b/arch/mips/vr41xx/common/Makefile
--- b-orig/arch/mips/vr41xx/common/Makefile	Sat Apr 23 22:59:07 2005
+++ b/arch/mips/vr41xx/common/Makefile	Sat Apr 23 22:59:48 2005
@@ -4,7 +4,6 @@
 
 obj-y				+= bcu.o cmu.o icu.o init.o int-handler.o pmu.o
 obj-$(CONFIG_GPIO_VR41XX)	+= giu.o
-obj-$(CONFIG_VRC4171)		+= vrc4171.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/common/vrc4171.c b/arch/mips/vr41xx/common/vrc4171.c
--- b-orig/arch/mips/vr41xx/common/vrc4171.c	Thu Jan 15 20:28:50 2004
+++ b/arch/mips/vr41xx/common/vrc4171.c	Thu Jan  1 09:00:00 1970
@@ -1,106 +0,0 @@
-/*
- *  vrc4171.c, NEC VRC4171 base driver.
- *
- *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#include <linux/init.h>
-#include <linux/ioport.h>
-#include <linux/module.h>
-#include <linux/types.h>
-
-#include <asm/io.h>
-#include <asm/vr41xx/vrc4171.h>
-
-MODULE_DESCRIPTION("NEC VRC4171 base driver");
-MODULE_AUTHOR("Yoichi Yuasa <yuasa@hh.iij4u.or.jp>");
-MODULE_LICENSE("GPL");
-
-EXPORT_SYMBOL_GPL(vrc4171_get_irq_status);
-EXPORT_SYMBOL_GPL(vrc4171_set_multifunction_pin);
-
-#define CONFIGURATION1		0x05fe
- #define SLOTB_CONFIG		0xc000
- #define SLOTB_NONE		0x0000
- #define SLOTB_PCCARD		0x4000
- #define SLOTB_CF		0x8000
- #define SLOTB_FLASHROM		0xc000
-
-#define CONFIGURATION2		0x05fc
-#define INTERRUPT_STATUS	0x05fa
-#define PCS_CONTROL		0x05ee
-#define GPIO_DATA		PCS_CONTROL
-#define PCS0_UPPER_START	0x05ec
-#define PCS0_LOWER_START	0x05ea
-#define PCS0_UPPER_STOP		0x05e8
-#define PCS0_LOWER_STOP		0x05e6
-#define PCS1_UPPER_START	0x05e4
-#define PCS1_LOWER_START	0x05e2
-#define PCS1_UPPER_STOP		0x05de
-#define PCS1_LOWER_STOP		0x05dc
-
-#define VRC4171_REGS_BASE	PCS1_LOWER_STOP
-#define VRC4171_REGS_SIZE	0x24
-
-uint16_t vrc4171_get_irq_status(void)
-{
-	return inw(INTERRUPT_STATUS);
-}
-
-void vrc4171_set_multifunction_pin(int config)
-{
-	uint16_t config1;
-
-	config1 = inw(CONFIGURATION1);
-	config1 &= ~SLOTB_CONFIG;
-
-	switch (config) {
-	case SLOTB_IS_NONE:
-		config1 |= SLOTB_NONE;
-		break;
-	case SLOTB_IS_PCCARD:
-		config1 |= SLOTB_PCCARD;
-		break;
-	case SLOTB_IS_CF:
-		config1 |= SLOTB_CF;
-		break;
-	case SLOTB_IS_FLASHROM:
-		config1 |= SLOTB_FLASHROM;
-		break;
-	default:
-		break;
-	}
-
-	outw(config1, CONFIGURATION1);
-}
-
-static int __devinit vrc4171_init(void)
-{
-	if (request_region(VRC4171_REGS_BASE, VRC4171_REGS_SIZE, "NEC VRC4171") == NULL)
-		return -EBUSY;
-
-	printk(KERN_INFO "NEC VRC4171 base driver\n");
-
-	return 0;
-}
-
-static void __devexit vrc4171_exit(void)
-{
-	release_region(VRC4171_REGS_BASE, VRC4171_REGS_SIZE);
-}
-
-module_init(vrc4171_init);
-module_exit(vrc4171_exit);
diff -urN -X dontdiff b-orig/include/asm-mips/vr41xx/vrc4171.h b/include/asm-mips/vr41xx/vrc4171.h
--- b-orig/include/asm-mips/vr41xx/vrc4171.h	Thu Jan 15 20:28:50 2004
+++ b/include/asm-mips/vr41xx/vrc4171.h	Thu Jan  1 09:00:00 1970
@@ -1,43 +0,0 @@
-/*
- *  vrc4171.h, Include file for NEC VRC4171.
- *
- *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#ifndef __NEC_VRC4171_H 
-#define __NEC_VRC4171_H 
-
-/*
- * Configuration 1
- */
-enum {
-	SLOTB_IS_NONE,       
-	SLOTB_IS_PCCARD,
-	SLOTB_IS_CF,
-	SLOTB_IS_FLASHROM
-};
-
-extern void vrc4171_set_multifunction_pin(int config);
-
-/*
- * Interrupt Status Mask
- */
-#define IRQ_A	0x02
-#define IRQ_B	0x04
-
-extern uint16_t vrc4171_get_irq_status(void);
-
-#endif /* __NEC_VRC4171_H */



From neoxx@canada.com Sun May 15 13:52:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 May 2005 13:53:15 +0100 (BST)
Received: from fh020.dia.cp.net ([IPv6:::ffff:64.97.160.30]:474 "EHLO
	n016.sc0.cp.net") by linux-mips.org with ESMTP id <S8224979AbVEOMw7>;
	Sun, 15 May 2005 13:52:59 +0100
Received: from smtp.sc0.cp.net (64.97.131.2) by n016.sc0.cp.net (7.0.038) (authenticated as neoxx@canada.com)
        id 42693F9F00403647 for linux-mips@linux-mips.org; Sun, 15 May 2005 12:52:48 +0000
Received: from [129.13.186.3] by mail.canada.com with HTTP; Sun,
    15 May 2005 05:52:47 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
From:	neoxx@canada.com
Subject: crosscompiler
X-Sent-From: neoxx@canada.com
Date:	Sun, 15 May 2005 05:52:47 -0700 (PDT)
X-Mailer: Web Mail 6.1.7-3.4_1
Message-Id: <20050515125247.7596.fh034.wm@smtp.sc0.cp.net>
Return-Path: <neoxx@canada.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7913
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: neoxx@canada.com
Precedence: bulk
X-list: linux-mips

Hi,

I wanna set up a crosscompiler on my intel machine (
using debian woody ) in order to cross-compile a
self-written kernel ( no Linux/Mips ) for a MIPS 4kc (
little endian ) CPU. 


I've set up the binutils ( 2.15 ). While trying to
compile gcc 3.3.4 ( --target=mipsel
--prefix=/usr/local/mipscross --enable-languages=c,c++
--without-headers ) the following error occurs:

 xgcc: installation problem, cannot exec `mips-tfile':
No such file or directory
make[2]: *** [libgcc/./_m16addsf3.o] Error 1
make[2]: Leaving directory
`/home/cag/finaltry/gcc-3.3.4/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory
`/home/cag/finaltry/gcc-3.3.4/gcc'
make: *** [all-gcc] Error 2

Any ideas how to fix that ?? Can I alternatively use
the mipsel-linux-gcc for the kernel ( I'm not quite
sure what sort of compiler that is... )

Thanks,

neoxx

From mile.davidovic@micronasnit.com Mon May 16 10:56:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 May 2005 10:57:09 +0100 (BST)
Received: from krt.tmd.ns.ac.yu ([IPv6:::ffff:147.91.177.65]:11205 "EHLO
	krt.neobee.net") by linux-mips.org with ESMTP id <S8225429AbVEPJ4v>;
	Mon, 16 May 2005 10:56:51 +0100
Received: from localhost (localhost [127.0.0.1])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4GA1rZF028213
	for <linux-mips@linux-mips.org>; Mon, 16 May 2005 12:01:58 +0200
Received: from krt.neobee.net ([127.0.0.1])
 by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 26129-06 for <linux-mips@linux-mips.org>;
 Mon, 16 May 2005 12:01:53 +0200 (CEST)
Received: from davidovic ([192.168.0.89])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4GA1V1p028192
	for <linux-mips@linux-mips.org>; Mon, 16 May 2005 12:01:42 +0200
Message-Id: <200505161001.j4GA1V1p028192@krt.neobee.net>
Reply-To: <mile.davidovic@micronasnit.com>
From:	"Mile Davidovic" <mile.davidovic@micronasnit.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Mips 4lkecr2 
Date:	Mon, 16 May 2005 11:57:02 +0200
Organization: MicronasNIT
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVZ/Ztp2O6Vmjq4Ra+I50hdZ4Uw4g==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Virus-Scanned: by amavisd-new at krt.neobee.net
Return-Path: <mile.davidovic@micronasnit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7914
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mile.davidovic@micronasnit.com
Precedence: bulk
X-list: linux-mips

Hello all

I have embedded processor with MIPS 4KECr2 processor and tried to port
linux-2.6.11-mipscvs-20050313.
I follow tutorial from linux-mips and add custom code for int handler, time
...
But I have some problem with detecting of cpu. In cpu-probe.c I added:
cpu_probe_mips with:
       case PRID_IMP_4KEC:
       case PRID_IMP_4KECR2:   /* this line is added */
        c->cputype = CPU_4KEC;
		c->isa_level = MIPS_CPU_ISA_M32;

Is it ok ? Did I forgot something?

I have problem with mem_init, here is output log, can You please tell me
what is problem with this?
Linux version 2.6.11-mipscvs-20050313-md (davidovic@rhel.micronasnit.com)
(gcc version 3.4.2) #207 Mon May 16 10:37:55 CEST 2005
CPU revision is: 00019064
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Built 1 zonelists
Kernel command line: 
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 8kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 512 (order: 9, 8192 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Bad page state at __free_pages_ok (in process 'swapper', page 810037c0)
flags:0x00000000 mapping:00000004 mapcount:0 count:0
Backtrace:
Call Trace:
 [<8004ca80>] bad_page+0x70/0xc0
 [<8004ceb0>] __free_pages_ok+0xb0/0x1d8
 [<8017a0a0>] free_all_bootmem_core+0x2c0/0x2d4
 [<8017acc8>] alloc_large_system_hash+0x28c/0x2fc
 [<80170a24>] mem_init+0x50/0x1b4
 [<8017c044>] inode_init_early+0x68/0xbc
 [<8016e604>] vgca_timer_setup+0xc8/0xfc
 [<80180000>] pcf8591_init+0x38/0x64
 [<801678c0>] start_kernel+0x15c/0x258
 [<801672b4>] unknown_bootoption+0x0/0x310
Trying to fix it up, but a reboot is needed
Bad page state at __free_pages_ok (in process 'swapper', page 810038c0)
flags:0x00000000 mapping:00002080 mapcount:0 count:0
Backtrace:
Call Trace:
 [<8004ca80>] bad_page+0x70/0xc0
 [<8004ceb0>] __free_pages_ok+0xb0/0x1d8
 [<8017a0a0>] free_all_bootmem_core+0x2c0/0x2d4
 [<8017acc8>] alloc_large_system_hash+0x28c/0x2fc
 [<80170a24>] mem_init+0x50/0x1b4
 [<8017c044>] inode_init_early+0x68/0xbc
 [<8016e604>] vgca_timer_setup+0xc8/0xfc
 [<80180000>] pcf8591_init+0x38/0x64
 [<801678c0>] start_kernel+0x15c/0x258
 [<801672b4>] unknown_bootoption+0x0/0x310

Here is my .config file:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-mipscvs-20050313
# Mon May 16 10:23:48 2005
#
CONFIG_MIPS=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION="-md"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_SHMEM is not set
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_TINY_SHMEM=y

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Machine selection
#
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_DB1550 is not set
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
CONFIG_MIPS_VGCA_EVA=y
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_NEC_OSPREY is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_SIBYTE_SWARM is not set
# CONFIG_SIBYTE_SENTOSA is not set
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_VGCA_HW_TOGGLE_BUG=y
CONFIG_VGCA_HW_RELOAD_BUG=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_NONCOHERENT=y
CONFIG_CPU_BIG_ENDIAN=y
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y
CONFIG_BOOT_ELF32=y
CONFIG_MIPS_L1_CACHE_SHIFT=5

#
# CPU selection
#
CONFIG_CPU_MIPS32=y
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
# CONFIG_CPU_SB1 is not set
CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y

#
# Kernel type
#
CONFIG_MIPS32=y
# CONFIG_MIPS64 is not set
# 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_CPU_HAS_PREFETCH=y
# CONFIG_64BIT_PHYS_ADDR is not set
CONFIG_CPU_ADVANCED=y
CONFIG_CPU_HAS_LLSC=y
# CONFIG_CPU_HAS_LLDSCD is not set
# CONFIG_CPU_HAS_WB is not set
CONFIG_CPU_HAS_SYNC=y
# CONFIG_PREEMPT is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_MMU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PC-card bridges
#

#
# PCI Hotplug Support
#

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_TRAD_SIGNALS=y
# CONFIG_BINFMT_IRIX is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#

#
# Networking support
#
# CONFIG_NET is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
# CONFIG_SERIO is not set
# CONFIG_SERIO_I8042 is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_VGCA=y
CONFIG_SERIAL_VGCA_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=y
# CONFIG_IPMI_SI is not set
CONFIG_IPMI_WATCHDOG=y
# CONFIG_IPMI_POWEROFF is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=y
CONFIG_RTC=y
CONFIG_DTLK=y
# CONFIG_R3964 is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ISA=y
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=y
CONFIG_SENSORS_ADM1021=y
CONFIG_SENSORS_ADM1025=y
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
CONFIG_SENSORS_DS1621=y
# CONFIG_SENSORS_FSCHER is not set
CONFIG_SENSORS_GL518SM=y
CONFIG_SENSORS_IT87=y
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=y
# CONFIG_SENSORS_LM77 is not set
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
CONFIG_SENSORS_LM87=y
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_SMSC47M1=y
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_PCF8574=y
CONFIG_SENSORS_PCF8591=y
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#

#
# Graphics support
#
# CONFIG_FB is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be
needed; see USB_STORAGE Help for more information
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
CONFIG_TMPFS_XATTR=y
CONFIG_TMPFS_SECURITY=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE=""
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_KGDB is not set
CONFIG_RUNTIME_DEBUG=y
# CONFIG_MIPS_UNCACHED is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y 

Best regards MIle


From macro@linux-mips.org Mon May 16 12:00:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 May 2005 12:01:09 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:31503 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225430AbVEPLAy>; Mon, 16 May 2005 12:00:54 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id AD618F5F8E; Mon, 16 May 2005 13:00:44 +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 22259-07; Mon, 16 May 2005 13:00:44 +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 550ACF5C8A; Mon, 16 May 2005 13:00:44 +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.1/8.13.1) with ESMTP id j4GAxu2c027225;
	Mon, 16 May 2005 13:00:47 +0200
Date:	Mon, 16 May 2005 12:00:02 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Mile Davidovic <mile.davidovic@micronasnit.com>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Mips 4lkecr2 
In-Reply-To: <200505161001.j4GA1V1p028192@krt.neobee.net>
Message-ID: <Pine.LNX.4.61L.0505161126220.15490@blysk.ds.pg.gda.pl>
References: <200505161001.j4GA1V1p028192@krt.neobee.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/879/Sun May 15 15:43:45 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7915
X-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, 16 May 2005, Mile Davidovic wrote:

> I have embedded processor with MIPS 4KECr2 processor and tried to port
> linux-2.6.11-mipscvs-20050313.
> I follow tutorial from linux-mips and add custom code for int handler, time
> ...
> But I have some problem with detecting of cpu. In cpu-probe.c I added:
> cpu_probe_mips with:
>        case PRID_IMP_4KEC:
>        case PRID_IMP_4KECR2:   /* this line is added */
>         c->cputype = CPU_4KEC;
> 		c->isa_level = MIPS_CPU_ISA_M32;
> 
> Is it ok ? Did I forgot something?

 Well, the processor is already supported in the current version of Linux.  
Had you chosen it for your port, you wouldn't have had to change anything.

> I have problem with mem_init, here is output log, can You please tell me
> what is problem with this?
> Linux version 2.6.11-mipscvs-20050313-md (davidovic@rhel.micronasnit.com)
> (gcc version 3.4.2) #207 Mon May 16 10:37:55 CEST 2005
> CPU revision is: 00019064
[...]
> Bad page state at __free_pages_ok (in process 'swapper', page 810037c0)
> flags:0x00000000 mapping:00000004 mapcount:0 count:0

 Please retry with the current version and if still failing, then send 
another report.

  Maciej

From ralf@linux-mips.org Mon May 16 18:49:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 May 2005 18:49:59 +0100 (BST)
Received: from p549F5CD4.dip.t-dialin.net ([IPv6:::ffff:84.159.92.212]:50662
	"EHLO bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225730AbVEPRto>; Mon, 16 May 2005 18:49:44 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4GHng53015780;
	Mon, 16 May 2005 18:49:42 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4GHnf1T015779;
	Mon, 16 May 2005 18:49:41 +0100
Date:	Mon, 16 May 2005 18:49:40 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Mile Davidovic <mile.davidovic@micronasnit.com>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Mips 4lkecr2
Message-ID: <20050516174940.GA31527@linux-mips.org>
References: <200505161001.j4GA1V1p028192@krt.neobee.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200505161001.j4GA1V1p028192@krt.neobee.net>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7916
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, May 16, 2005 at 11:57:02AM +0200, Mile Davidovic wrote:

> I have embedded processor with MIPS 4KECr2 processor and tried to port
> linux-2.6.11-mipscvs-20050313.
> I follow tutorial from linux-mips and add custom code for int handler, time
> ...
> But I have some problem with detecting of cpu. In cpu-probe.c I added:
> cpu_probe_mips with:
>        case PRID_IMP_4KEC:
>        case PRID_IMP_4KECR2:   /* this line is added */
>         c->cputype = CPU_4KEC;
> 		c->isa_level = MIPS_CPU_ISA_M32;
> 
> Is it ok ? Did I forgot something?

To get Linux to work on a 4KEc R2 Malta I only had to to do this change
so you have an additional problem.

  Ralf

From steve-alexander@adelphia.net Tue May 17 07:20:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 07:20:49 +0100 (BST)
Received: from mta9.adelphia.net ([IPv6:::ffff:68.168.78.199]:26763 "EHLO
	mta9.adelphia.net") by linux-mips.org with ESMTP
	id <S8225282AbVEQGUe>; Tue, 17 May 2005 07:20:34 +0100
Received: from boletus ([69.168.160.197]) by mta9.adelphia.net
          (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP
          id <20050517062022.SUH8952.mta9.adelphia.net@boletus>
          for <linux-mips@linux-mips.org>; Tue, 17 May 2005 02:20:22 -0400
Message-ID: <053301c55aa8$887769e0$0300a8c0@boletus>
From:	"Steve Alexander" <steve-alexander@adelphia.net>
To:	"linux-mips" <linux-mips@linux-mips.org>
References: <20050513222528.010b2a4d.yuasa@hh.iij4u.or.jp>
Subject: help
Date:	Tue, 17 May 2005 02:20:33 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Return-Path: <steve-alexander@adelphia.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7917
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: steve-alexander@adelphia.net
Precedence: bulk
X-list: linux-mips

help

From eckhardt@satorlaser.com Tue May 17 08:13:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 08:13:30 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.186]:39151
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226027AbVEQHNO>; Tue, 17 May 2005 08:13:14 +0100
Received: from [213.39.254.68] (helo=tuxator.satorlaser-intern.com)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0MKwpI-1DXwGN1nCm-0005LH; Tue, 17 May 2005 09:13:11 +0200
From:	Ulrich Eckhardt <eckhardt@satorlaser.com>
Organization: Sator Laser GmbH
To:	linux-mips@linux-mips.org
Subject: Re: crosscompiler
Date:	Tue, 17 May 2005 09:14:48 +0200
User-Agent: KMail/1.7.2
References: <20050515125247.7596.fh034.wm@smtp.sc0.cp.net>
In-Reply-To: <20050515125247.7596.fh034.wm@smtp.sc0.cp.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505170914.48879.eckhardt@satorlaser.com>
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:e35cee35a663f5c944b9750a965814ae
Return-Path: <eckhardt@satorlaser.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7918
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eckhardt@satorlaser.com
Precedence: bulk
X-list: linux-mips

neoxx@canada.com wrote:
> I wanna set up a crosscompiler on my intel machine (
> using debian woody ) in order to cross-compile a
> self-written kernel ( no Linux/Mips ) for a MIPS 4kc (
> little endian ) CPU.

I'm using Debian/testing here and roughly followed
http://people.debian.org/~debacle/cross.html in order to get a working system. 
Almost no problems encountered.

> Can I alternatively use
> the mipsel-linux-gcc for the kernel ( I'm not quite
> sure what sort of compiler that is... )

mips= for MIPS
el= endianess little

IOW, this is precisely what I got from installing the crosscompiler and 
probably what you want. In order to compile non-Linux programs (i.e. programs 
launched directly from YAMON) I used these 
  CFLAGS += -Wall -mips32 -fno-builtin -mno-abicalls -fno-pic -GO -O2
though some of them might be redundant/unnecessary - I just tried combinations 
until it worked.

hth

Uli


From belamina1@yahoo.com Tue May 17 10:36:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 10:36:58 +0100 (BST)
Received: from web32507.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.217]:58493
	"HELO web32507.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8226150AbVEQJgm>; Tue, 17 May 2005 10:36:42 +0100
Received: (qmail 76785 invoked by uid 60001); 17 May 2005 09:36:33 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=MJzQhQTcW7MssD9Z5SrYxkHIQGyEb8eaPt1hiNhBVxu3vMUNubDbJ4Oc3IWqhJk8YFd9RcJjRNYNUih7QRf18qlv8SVHOA2Snlnw7rievAf3ATuPV4rsCljEQRAT1BDYcsyporpYIgXAv7DIOj4Ghwr5azszU+Xirhf1ku/asWg=  ;
Message-ID: <20050517093633.76783.qmail@web32507.mail.mud.yahoo.com>
Received: from [85.250.113.238] by web32507.mail.mud.yahoo.com via HTTP; Tue, 17 May 2005 02:36:32 PDT
Date:	Tue, 17 May 2005 02:36:32 -0700 (PDT)
From:	Michael Belamina <belamina1@yahoo.com>
Subject: 64 bit kernel for BCM1250
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <belamina1@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7919
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belamina1@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

  I have built a 64 bit kernel for BCM1250.
  When the kernel is loaded and control is passed to
kernel_entry there is an exception:

CFE> boot -elf LinuxServer:vmlinux.64
Loader:elf Filesys:tftp Dev:eth2
File:LinuxServer:vmlinux.64 Options:(null)
Loading: 0xffffffff80100000/2162688
0xffffffff80310000/557344 Entry at 0xffffffff802d0000
Closing network.
Starting program at 0xffffffff802d0000
**Exception 8: EPC=FFFFFFFF802D003C, Cause=0000900C
(TLBMissWr)
                RA=FFFFFFFF9FC0086C,
VAddr=0000000000000000

        0  ($00) = 0000000000000000     AT ($01) =
0000000000000000
        v0 ($02) = 0000000000000080     v1 ($03) =
0000000000000003
        a0 ($04) = FFFFFFFF81F07FF0     a1 ($05) =
0000000000000000
        a2 ($06) = FFFFFFFF9FC008E8     a3 ($07) =
0000000043464531
        t0 ($08) = FFFFFFFF802D0000     t1 ($09) =
FFFFFFFF81F01DB8
        t2 ($10) = FFFFFFFFA0008000     t3 ($11) =
0000000000008000
        t4 ($12) = 0000000000000000     t5 ($13) =
FFFFFFFF81F18E60
        t6 ($14) = FFFFFFFF81F14A20     t7 ($15) =
000000000000000A
        s0 ($16) = FFFFFFFF9FC0086C     s1 ($17) =
FFFFFFFF81F01D20
        s2 ($18) = FFFFFFFF820036F8     s3 ($19) =
FFFFFFFF81F00000
        s4 ($20) = FFFFFFFF820036E8     s5 ($21) =
FFFFFFFFFFFFFFFF
        s6 ($22) = 0000000000000000     s7 ($23) =
0000000000000000
        t8 ($24) = 0000000010000000     t9 ($25) =
FFFFFFFF9FC46430
        k0 ($26) = FFFFFFFF81F22E28     k1 ($27) =
FFFFFFFF81F1F098
        gp ($28) = FFFFFFFF81F07FF0     sp ($29) =
FFFFFFFF82003550
        fp ($30) = 0000000000000000     ra ($31) =
FFFFFFFF9FC0086C



The code where the exception occurs is:
ffffffff802d0000 <kernel_entry>:
ffffffff802d0000:       400c6000        mfc0   
t0,c0_status
ffffffff802d0004:       3c011000        lui    
at,0x1000
ffffffff802d0008:       3421009f        ori    
at,at,0x9f
ffffffff802d000c:       01816025        or     
t0,t0,at
ffffffff802d0010:       398c001f        xori   
t0,t0,0x1f
ffffffff802d0014:       408c6000        mtc0   
t0,c0_status
ffffffff802d0018:       000000c0        sll    
zero,zero,0x3
ffffffff802d001c:       37bd000f        ori    
sp,sp,0xf
ffffffff802d0020:       3bbd000f        xori   
sp,sp,0xf
ffffffff802d0024:       3c0c0000        lui     t0,0x0
ffffffff802d0028:       3c010000        lui     at,0x0
ffffffff802d002c:       658c0000        daddiu 
t0,t0,0
ffffffff802d0030:       64210000        daddiu 
at,at,0
ffffffff802d0034:       000c603c        dsll32 
t0,t0,0x0
ffffffff802d0038:       0181602d        daddu  
t0,t0,at
ffffffff802d003c:       fd800000        sd     
zero,0(t0) 
ffffffff802d0040:       3c0d0000        lui     t1,0x0
ffffffff802d0044:       3c010000        lui     at,0x0
ffffffff802d0048:       65ad0000        daddiu 
t1,t1,0
ffffffff802d004c:       6421fff8        daddiu 
at,at,-8
ffffffff802d0050:       000d683c        dsll32 
t1,t1,0x0
ffffffff802d0054:       01a1682d        daddu  
t1,t1,at
ffffffff802d0058:       658c0008        daddiu 
t0,t0,8
ffffffff802d005c:       158dfffe        bne    
t0,t1,ffffffff802d0058 <__init_begin+0x58>
ffffffff802d0060:       fd800000        sd     
zero,0(t0)
ffffffff802d0064:       3c1c0000        lui     gp,0x0
ffffffff802d0068:       3c010000        lui     at,0x0


A 32 bit kernel loads and boot with no problems on the
same board. The board design is based on Sentosa. The
boot loader is CFE. The kernel version is 2.4.28

Please advice.
 
Thank,
  Michael




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

From mile.davidovic@micronasnit.com Tue May 17 11:15:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 11:15:49 +0100 (BST)
Received: from krt.tmd.ns.ac.yu ([IPv6:::ffff:147.91.177.65]:12966 "EHLO
	krt.neobee.net") by linux-mips.org with ESMTP id <S8226180AbVEQKPd>;
	Tue, 17 May 2005 11:15:33 +0100
Received: from localhost (localhost [127.0.0.1])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4HAKoZF031081
	for <linux-mips@linux-mips.org>; Tue, 17 May 2005 12:20:56 +0200
Received: from krt.neobee.net ([127.0.0.1])
 by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 30287-05 for <linux-mips@linux-mips.org>;
 Tue, 17 May 2005 12:20:50 +0200 (CEST)
Received: from davidovic ([192.168.0.89])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4HAKh1p031076
	for <linux-mips@linux-mips.org>; Tue, 17 May 2005 12:20:43 +0200
Message-Id: <200505171020.j4HAKh1p031076@krt.neobee.net>
Reply-To: <mile.davidovic@micronasnit.com>
From:	"Mile Davidovic" <mile.davidovic@micronasnit.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: Mips 4lkecr2
Date:	Tue, 17 May 2005 12:16:07 +0200
Organization: MicronasNIT
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <20050516174940.GA31527@linux-mips.org>
Thread-Index: AcVaQXwE8CLCWORGTEeQW88iB6fyfAAhu+2g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Virus-Scanned: by amavisd-new at krt.neobee.net
Return-Path: <mile.davidovic@micronasnit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7920
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mile.davidovic@micronasnit.com
Precedence: bulk
X-list: linux-mips

Hello all

Here is output from latest (2.6.12-rc3) linux-mips version. What is problem
with mem_init function?


 Linux version 2.6.12-rc3-md (davidovic@rhel.micronasnit.com) (gcc version
3.4.2) #14 Tue May 17 11:06:34 CEST 2005
 CPU revision is: 00019064
 Determined physical RAM map:
  memory: 04000000 @ 00000000 (usable)
 Built 1 zonelists
 Kernel command line: 
 Primary instruction cache 16kB, physically tagged, 4-way, linesize 16
bytes.
 Primary data cache 8kB, 2-way, linesize 16 bytes.
 Synthesized TLB refill handler (20 instructions).
 Synthesized TLB load handler fastpath (32 instructions).
 Synthesized TLB store handler fastpath (32 instructions).
 Synthesized TLB modify handler fastpath (31 instructions).
 PID hash table entries: 512 (order: 9, 8192 bytes)
 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
 Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
 Bad page state at free_hot_cold_page (in process 'swapper', page 81003180)
 flags:0x00000000 mapping:00000000 mapcount:-65535 count:0
 Backtrace:
 Call Trace:
  [<80052440>] bad_page+0x70/0xc0
  [<800296c4>] vprintk+0x38c/0x460
  [<80162b28>] build_tlb_refill_handler+0xdcc/0xea8
  [<80052bec>] free_hot_cold_page+0x88/0x284
  [<80169e48>] free_all_bootmem_core+0x174/0x2d4
  [<8016ab88>] alloc_large_system_hash+0x28c/0x2fc
  [<80160868>] mem_init+0x50/0x1b4
  [<8016bf74>] inode_init_early+0x68/0xbc
  [<8015e070>] vgca_timer_setup+0xc8/0xfc
  [<80157910>] start_kernel+0x17c/0x254
  [<801572e4>] unknown_bootoption+0x0/0x310
 
 Trying to fix it up, but a reboot is needed
 Bad page state at free_hot_cold_page (in process 'swapper', page 81003280)
 flags:0x0000525a mapping:00000000 mapcount:0 count:0
 Backtrace:
 Call Trace:
  [<80052440>] bad_page+0x70/0xc0
  [<800296c4>] vprintk+0x38c/0x460
  [<80162b28>] build_tlb_refill_handler+0xdcc/0xea8
  [<80052bec>] free_hot_cold_page+0x88/0x284
  [<80169e48>] free_all_bootmem_core+0x174/0x2d4
  [<8016ab88>] alloc_large_system_hash+0x28c/0x2fc
  [<80160868>] mem_init+0x50/0x1b4
  [<8016bf74>] inode_init_early+0x68/0xbc
  [<8015e070>] vgca_timer_setup+0xc8/0xfc
  [<80157910>] start_kernel+0x17c/0x254
  [<801572e4>] unknown_bootoption+0x0/0x310 

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org] 
Sent: Monday, May 16, 2005 7:50 PM
To: Mile Davidovic
Cc: 'Linux/MIPS Development'
Subject: Re: Mips 4lkecr2

On Mon, May 16, 2005 at 11:57:02AM +0200, Mile Davidovic wrote:

> I have embedded processor with MIPS 4KECr2 processor and tried to port 
> linux-2.6.11-mipscvs-20050313.
> I follow tutorial from linux-mips and add custom code for int handler, 
> time ...
> But I have some problem with detecting of cpu. In cpu-probe.c I added:
> cpu_probe_mips with:
>        case PRID_IMP_4KEC:
>        case PRID_IMP_4KECR2:   /* this line is added */
>         c->cputype = CPU_4KEC;
> 		c->isa_level = MIPS_CPU_ISA_M32;
> 
> Is it ok ? Did I forgot something?

To get Linux to work on a 4KEc R2 Malta I only had to to do this change so
you have an additional problem.

  Ralf


From macro@linux-mips.org Tue May 17 11:49:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 11:50:05 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:39695 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226195AbVEQKtu>; Tue, 17 May 2005 11:49:50 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id C014EF5A39; Tue, 17 May 2005 12:49:44 +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 05584-07; Tue, 17 May 2005 12:49:44 +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 8AC03F5A2C; Tue, 17 May 2005 12:49:44 +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.1/8.13.1) with ESMTP id j4HAnkls004589;
	Tue, 17 May 2005 12:49:46 +0200
Date:	Tue, 17 May 2005 11:49:52 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Michael Belamina <belamina1@yahoo.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: 64 bit kernel for BCM1250
In-Reply-To: <20050517093633.76783.qmail@web32507.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61L.0505171145040.17529@blysk.ds.pg.gda.pl>
References: <20050517093633.76783.qmail@web32507.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/882/Tue May 17 08:48:03 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7921
X-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, 17 May 2005, Michael Belamina wrote:

>   I have built a 64 bit kernel for BCM1250.
>   When the kernel is loaded and control is passed to
> kernel_entry there is an exception:
> 
> CFE> boot -elf LinuxServer:vmlinux.64
[...]

 I'm assuming vmlinux.64 is a 64-bit ELF file.  If so, then, well, 
depending on the version of CFE you have, this may or may not work.  The 
workaround is to always use 32-bit ELF files.  You should get one after 
your Linux build -- if not (which may depend on how you do builds), then 
try `make vmlinux.32' and use the result.

  Maciej

From jerry@izmiran.rssi.ru Tue May 17 12:21:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 12:21:25 +0100 (BST)
Received: from cygnus.izmiran.rssi.ru ([IPv6:::ffff:193.232.24.21]:15796 "EHLO
	cygnus.izmiran.rssi.ru") by linux-mips.org with ESMTP
	id <S8226198AbVEQLVK>; Tue, 17 May 2005 12:21:10 +0100
Received: from [127.0.0.1] (IDENT:10003@localhost [127.0.0.1])
	by cygnus.izmiran.rssi.ru (8.12.4/8.12.4) with ESMTP id j4HBKscs019966
	for <linux-mips@linux-mips.org>; Tue, 17 May 2005 15:20:59 +0400
Date:	Tue, 17 May 2005 14:22:17 +0300
From:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: "Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Organization: Home
X-Priority: 3 (Normal)
Message-ID: <1547700103.20050517142217@izmiran.rssi.ru>
To:	linux-mips <linux-mips@linux-mips.org>
Subject: au1200 status
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit
Return-Path: <jerry@izmiran.rssi.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7922
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@izmiran.rssi.ru
Precedence: bulk
X-list: linux-mips

  Hello all

  Dealing with my new DBau1200 board and last 2.6 kernel I found that
there's a few things came into from 2.4 kernel, which is distributed
by AMD with this board. In 2.6 we have no ethernet driver (thanks to
Pete I solved this issue (temporarily?)), furthermore we have no LCD
driver, no sound driver, etc... What status of it? Will these drivers
migrate from 2.4 to 2.6 tree (and how soon?)  Or there's something
different politics?

  Some time ago I saw a old report for some au1* boards usability and
patches for them - maybe I should look for them?

  In addition, somewhere I met the info that such things like MAE,
AES, MTD drivers must be done (by AMD?) in 1st quarter 2005. Anyhow, I
see no any info about them.. Did I missed something?



   ()_()
--( °,° )---[21398845]-[jerry¤wicomtechnologies.com]-
  (") (")                 -<The Bat! 3.0.1.33>- -<17/05/2005 14:05>-


From ppopov@embeddedalley.com Tue May 17 15:58:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 15:59:14 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:33172
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226233AbVEQO65>; Tue, 17 May 2005 15:58:57 +0100
Received: from unknown (HELO ?192.168.1.105?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 17 May 2005 14:58:52 -0000
Subject: Re: au1200 status
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1547700103.20050517142217@izmiran.rssi.ru>
References: <1547700103.20050517142217@izmiran.rssi.ru>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 17 May 2005 07:59:02 -0700
Message-Id: <1116341942.5802.15.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7923
X-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 Tue, 2005-05-17 at 14:22 +0300, Ruslan V.Pisarev wrote:
>   Hello all
> 
>   Dealing with my new DBau1200 board and last 2.6 kernel I found that
> there's a few things came into from 2.4 kernel, which is distributed
> by AMD with this board. In 2.6 we have no ethernet driver (thanks to
> Pete I solved this issue (temporarily?)), furthermore we have no LCD
> driver, no sound driver, etc... What status of it? Will these drivers
> migrate from 2.4 to 2.6 tree (and how soon?)  Or there's something
> different politics?

The Au1200 support will from migrate from 2.4 to 2.6 when either someone
funds the effort or someone has time to do it for fun.

>   Some time ago I saw a old report for some au1* boards usability and
> patches for them - maybe I should look for them?
> 
>   In addition, somewhere I met the info that such things like MAE,
> AES, MTD drivers must be done (by AMD?) in 1st quarter 2005. Anyhow, I
> see no any info about them.. Did I missed something?

Perhaps they were talking about 2.4, not 2.6.

Pete


From belamina1@yahoo.com Tue May 17 20:52:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2005 20:53:00 +0100 (BST)
Received: from web32503.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.213]:57942
	"HELO web32503.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8226315AbVEQTwo>; Tue, 17 May 2005 20:52:44 +0100
Received: (qmail 40788 invoked by uid 60001); 17 May 2005 19:52:32 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=LBysdeL0ujsPg5Wsf/Roll0muB5wnfFILoCtMcjgfEEayNMu73JTzdKqSx+nJBAYRxGk87xkNaeUSTl68o1aVHdGBeoQGVeYeuqGaPl+II7lnM4vD/sbz+FGO8Qv4Yd37PpxqTckgEdXSvMay6Lyn0k3dBIKRnEZ3Zgj9NpSkSA=  ;
Message-ID: <20050517195232.40786.qmail@web32503.mail.mud.yahoo.com>
Received: from [85.250.113.238] by web32503.mail.mud.yahoo.com via HTTP; Tue, 17 May 2005 12:52:32 PDT
Date:	Tue, 17 May 2005 12:52:32 -0700 (PDT)
From:	Michael Belamina <belamina1@yahoo.com>
Subject: Re: 64 bit kernel for BCM1250
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <belamina1@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7924
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belamina1@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

  Thanks for your reply.
  I tried using the resulted vmlinux.32 and got the
same result. 

  After looking into it, I found out that t0 is loaded
with 0x0 while it should load _edata value which
should be 0xffffffff80310000 (according to the
System.map).   in the 32 bit version (which I build
using a different toolchain), edata is loaded to t0
register as it should.

It looks to me like it is a toolchain problem. 

1. where can I download a pre built, prooven working
64 bit toolchain?

2. Is there anything else that can cause this problem?


Thanks,
 Michael


--- "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> On Tue, 17 May 2005, Michael Belamina wrote:
> 
> >   I have built a 64 bit kernel for BCM1250.
> >   When the kernel is loaded and control is passed
> to
> > kernel_entry there is an exception:
> > 
> > CFE> boot -elf LinuxServer:vmlinux.64
> [...]
> 
>  I'm assuming vmlinux.64 is a 64-bit ELF file.  If
> so, then, well, 
> depending on the version of CFE you have, this may
> or may not work.  The 
> workaround is to always use 32-bit ELF files.  You
> should get one after 
> your Linux build -- if not (which may depend on how
> you do builds), then 
> try `make vmlinux.32' and use the result.
> 
>   Maciej
> 

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

From belamina1@yahoo.com Wed May 18 09:09:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 May 2005 09:09:42 +0100 (BST)
Received: from web32501.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.211]:3668
	"HELO web32501.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8224953AbVERIJZ>; Wed, 18 May 2005 09:09:25 +0100
Received: (qmail 45524 invoked by uid 60001); 18 May 2005 08:09:17 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=CgD2XZEZZlCHAdtuOyvudEuKn9pXmQTVcNOD00dX+Tb32MgIsr7GZrOqCOHTJL7/aRAxuzQ3Dm+Dy8+Npo3gp1N47sUYmJLsqnSEw86zYDocTqFQOAh6prZrzIhMcF0UoWvg3dqCJsnCR0NwEfY/nFti5RurFR/m0JZj1ZXwhOs=  ;
Message-ID: <20050518080917.45521.qmail@web32501.mail.mud.yahoo.com>
Received: from [85.250.113.238] by web32501.mail.mud.yahoo.com via HTTP; Wed, 18 May 2005 01:09:17 PDT
Date:	Wed, 18 May 2005 01:09:17 -0700 (PDT)
From:	Michael Belamina <belamina1@yahoo.com>
Subject: Re: 64 bit kernel for BCM1250
To:	linux-mips@linux-mips.org
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <belamina1@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7925
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belamina1@yahoo.com
Precedence: bulk
X-list: linux-mips


I downloaded a new toolchain from ftp.mips-linux.org 
 and the previous problem is not repeating itself (t0
is now loaded properly with the _edata value). 

 Now I have another problem. I am getting the
following exception:


----  Start of pasted message  ---------

Starting program at 0xffffffff802ec000
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250E (Sentosa)
@@@@ This is a BCM1250 B1/B2, but the kernel is
conservatively configured for an 'A' stepping. @@@@
This kernel optimized for board runs with CFE
CPU revision is: 01040102
FPU revision is: 000f0102
Primary instruction cache 32kB, 4-way, linesize 32
bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Linux version 2.4.30 (michael@LinuxServer.lan) (gcc
version 3.4.3) #29 SMP Wed May 18 10:37:00 IDT 2005
Determined physical RAM map:
 memory: 0000000001effe00 @ 0000000000000000 (usable)
 memory: 000000000dffbe00 @ 0000000002004000 (usable)
 memory: 000000000ffffe00 @ 0000000080000000 (usable)
On node 0 totalpages: 589823
zone(0): 589823 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs ip=any
ramdisk_size=48000
Calibrating delay loop... 532.48 BogoMIPS
Memory: 468216k/523236k available (1951k kernel code,
55020k reserved, 148k data, 112k init)
Dentry cache hash table entries: 131072 (order: 9,
2097152 bytes)
Inode cache hash table entries: 131072 (order: 9,
2097152 bytes)
Mount cache hash table entries: 256 (order: 0, 4096
bytes)
Buffer cache hash table entries: 262144 (order: 9,
2097152 bytes)
Page-cache hash table entries: 262144 (order: 9,
2097152 bytes)
Checking for 'wait' instruction...  unavailable.
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
POSIX conformance testing by UNIFIX
Detected 2 available CPU(s)
Starting CPU 1...
Primary instruction cache 32kB, 4-way, linesize 32
bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Slave cpu booted successfully
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
pipe_mnt =                0
Cpu 0 Unable to handle kernel paging request at
address 0000000000000028, epc == ffffffff8016e3bc, ra
== ffffffff8014
Oops in fault.c::do_page_fault, line 231:
Cpu 0
$0      : 0000000000000000 ffffffff803b0000
0000000000000000 0000000000000009
$4      : ffffffff802c31ba ffffffff802c45f2
0000000000000072 0000000000000000
$8      : ffffffff803bf630 ffffffff803bf630
ffffffff803bd550 000000000000000a
$12     : ffffffffffffffff ffffffff8039b487
0000000000000000 ffffffff802bf0d0
$16     : ffffffff80100098 a80000008fff6080
ffffffffffffffe9 a80000008fff6140
$20     : 0000000000000000 ffffffff803078c0
0000000000000001 ffffffff80324688
$24     : 0000000000000000 0000000000000020
$28     : ffffffff802e8000 ffffffff802ebce0
ffffffff802ebd70 ffffffff8016e3c4
Hi      : 0000000000000000
Lo      : 0000000000000000
epc     : ffffffff8016e3bc    Not tainted
badvaddr: 0000000000000028
Status  : 14001fe3  [ KX SX UX KERNEL EXL IE ]
Cause   : 80808008
PrId  : 01040102
Process swapper (pid: 0, stackpage=ffffffff802e8000)
Stack: 0000000000000000 0000000000040004
0000000000000000 9000000010060120
       9000000010060100 ffffffff803bd550
ffffffff803bf630 ffffffff803bf630
       ffffffff80100098 0000000000000000
0000000000010f00 ffffffff80307860
       0000000000000000 ffffffff803078c0
0000000000000001 ffffffff80324688
       0000000000000000 ffffffff8010a0c8
ffffffffffffffff 000000000000000a
       ffffffff80107e2c 0000000000000000
0000000000000000 0000000000000020
       0000000000000001 000000000000000a
ffffffff802e8000 ffffffff802ebe00
       0000000000000000 ffffffff8021458c
00000000000013bf c000000000000000
       0000000000010f00 0000000000000000
ffffffff802ebef0 0000000000000fc0
       ffffffffffffffc0 0000000000000000
0000000014001fe1 ffffffff8039b488
       000000000000003e ...
Call Trace: [<ffffffff80100098>] [<ffffffff8010a0c8>]
[<ffffffff80107e2c>]
            [<ffffffff8021458c>] [<ffffffff80100098>]
[<ffffffff8012583c>]
            [<ffffffff80105488>] [<ffffffff8012583c>]

Code: dc42a5f0  104000fc  00000000 <0c05ffcc> dc440028
 104000e7  0040802d  0c05b892  0040202d
Kernel panic: Attempted to kill the idle task!
In idle task - not syncing
 <0>Rebooting in 5 seconds..Passing control back to
CFE...


----  End of pasted message  ---------


The fault is in do_pipe() function when trying to
call:

struct inode *inode = new_inode(pipe_mnt->mnt_sb);

The pipe_mnt is NULL at this point because
init_pipe_fs () was not called yet.


Any ideas what could be wrong?

Thanks,
  Michael






--- "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> On Tue, 17 May 2005, Michael Belamina wrote:
> 
> >   I have built a 64 bit kernel for BCM1250.
> >   When the kernel is loaded and control is passed
> to
> > kernel_entry there is an exception:
> > 
> > CFE> boot -elf LinuxServer:vmlinux.64
> [...]
> 
>  I'm assuming vmlinux.64 is a 64-bit ELF file.  If
> so, then, well, 
> depending on the version of CFE you have, this may
> or may not work.  The 
> workaround is to always use 32-bit ELF files.  You
> should get one after 
> your Linux build -- if not (which may depend on how
> you do builds), then 
> try `make vmlinux.32' and use the result.
> 
>   Maciej
> 

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

From ddaney@avtrex.com Wed May 18 16:59:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 May 2005 16:59:22 +0100 (BST)
Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:7968
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225210AbVERP7F>;
	Wed, 18 May 2005 16:59:05 +0100
Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 18 May 2005 08:58:58 -0700
Message-ID: <428B663C.7050308@avtrex.com>
Date:	Wed, 18 May 2005 08:58:52 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Michael Belamina <belamina1@yahoo.com>
CC:	linux-mips@linux-mips.org
Subject: Re: 64 bit kernel for BCM1250
References: <20050518080917.45521.qmail@web32501.mail.mud.yahoo.com>
In-Reply-To: <20050518080917.45521.qmail@web32501.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2005 15:58:58.0530 (UTC) FILETIME=[805D2C20:01C55BC2]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7926
X-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

Michael Belamina wrote:
.
.
.
> Linux version 2.4.30 (michael@LinuxServer.lan) (gcc
> version 3.4.3) #29 SMP Wed May 18 10:37:00 IDT 2005
.
.
.
> 
> The fault is in do_pipe() function when trying to
> call:
> 
> struct inode *inode = new_inode(pipe_mnt->mnt_sb);
> 
> The pipe_mnt is NULL at this point because
> init_pipe_fs () was not called yet.
> 
> 
> Any ideas what could be wrong?
> 

I saw this with a 32 bit kernel (for a 32 bit target).  As far as I 
know, no 2.4.x kernels from linux-mips.org will work with gcc 3.4.x.

I have previously posted patches to this list that fixed the problem for 
me.  Specifically I think the messages in this thread are relevant:

http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=41AFDA18.2010906%40avtrex.com

David Daney.

From macro@linux-mips.org Wed May 18 17:24:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 May 2005 17:24:20 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:11534 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225210AbVERQYD>; Wed, 18 May 2005 17:24:03 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id B83B7F5B1F; Wed, 18 May 2005 18:23:52 +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 20666-01; Wed, 18 May 2005 18:23:52 +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 6CAF9F597A; Wed, 18 May 2005 18:23:52 +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.1/8.13.1) with ESMTP id j4IGNuoE023626;
	Wed, 18 May 2005 18:23:56 +0200
Date:	Wed, 18 May 2005 17:24:04 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	David Daney <ddaney@avtrex.com>
Cc:	Michael Belamina <belamina1@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: 64 bit kernel for BCM1250
In-Reply-To: <428B663C.7050308@avtrex.com>
Message-ID: <Pine.LNX.4.61L.0505181715070.19170@blysk.ds.pg.gda.pl>
References: <20050518080917.45521.qmail@web32501.mail.mud.yahoo.com>
 <428B663C.7050308@avtrex.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/886/Wed May 18 12:32:36 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7927
X-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, 18 May 2005, David Daney wrote:

> I saw this with a 32 bit kernel (for a 32 bit target).  As far as I know, no
> 2.4.x kernels from linux-mips.org will work with gcc 3.4.x.

 That could actually be true -- I've been using GCC 4.0.0 for quite some 
time now (that includes CVS snapshots from before the release), so I have 
no slightest idea whether it's OK to use older versions. ;-)

> I have previously posted patches to this list that fixed the problem for me.
> Specifically I think the messages in this thread are relevant:
> 
> http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=41AFDA18.2010906%40avtrex.com

 Hasn't one of the proposed fixes for the bug made its way to Linux in the 
end?  That would be regrettable...

  Maciej

From ddaney@avtrex.com Wed May 18 17:35:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 May 2005 17:36:02 +0100 (BST)
Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:14114
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225218AbVERQfr>;
	Wed, 18 May 2005 17:35:47 +0100
Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 18 May 2005 09:35:44 -0700
Message-ID: <428B6EDD.4040508@avtrex.com>
Date:	Wed, 18 May 2005 09:35:41 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
CC:	Michael Belamina <belamina1@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: 64 bit kernel for BCM1250
References: <20050518080917.45521.qmail@web32501.mail.mud.yahoo.com> <428B663C.7050308@avtrex.com> <Pine.LNX.4.61L.0505181715070.19170@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.61L.0505181715070.19170@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2005 16:35:44.0760 (UTC) FILETIME=[A3612780:01C55BC7]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7928
X-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

Maciej W. Rozycki wrote:
> On Wed, 18 May 2005, David Daney wrote:
> 
> 
>>I saw this with a 32 bit kernel (for a 32 bit target).  As far as I know, no
>>2.4.x kernels from linux-mips.org will work with gcc 3.4.x.
> 
> 
>  That could actually be true -- I've been using GCC 4.0.0 for quite some 
> time now (that includes CVS snapshots from before the release), so I have 
> no slightest idea whether it's OK to use older versions. ;-)
> 
> 
>>I have previously posted patches to this list that fixed the problem for me.
>>Specifically I think the messages in this thread are relevant:
>>
>>http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=41AFDA18.2010906%40avtrex.com
> 
> 
>  Hasn't one of the proposed fixes for the bug made its way to Linux in the 
> end?  That would be regrettable...
> 

WRT the 2.4 kernel the answer seems to be no.  And yes I think it is 
regrettable.

If anybody thinks it would be useful, I could post my current patch again.

David Daney.

From adi@hexapodia.org Wed May 18 20:32:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 May 2005 20:33:07 +0100 (BST)
Received: from straum.hexapodia.org ([IPv6:::ffff:64.81.70.185]:14452 "EHLO
	straum.hexapodia.org") by linux-mips.org with ESMTP
	id <S8225265AbVERTcr>; Wed, 18 May 2005 20:32:47 +0100
Received: by straum.hexapodia.org (Postfix, from userid 22448)
	id AA7CC29C; Wed, 18 May 2005 12:32:12 -0700 (PDT)
Date:	Wed, 18 May 2005 12:32:12 -0700
From:	Andy Isaacson <adi@hexapodia.org>
To:	linux-mips@linux-mips.org
Subject: rsync down?
Message-ID: <20050518193212.GA20945@hexapodia.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2i
X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1  B8 DF 39 B2 AF A3 16 B9
X-PGP-Key-URL: http://web.hexapodia.org/~adi/pgp.txt
X-Domestic-Surveillance: money launder bomb tax evasion
Return-Path: <adi@hexapodia.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7929
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adi@hexapodia.org
Precedence: bulk
X-list: linux-mips

It appears that ftp.linux-mips.org is not listening on port 873.  I
don't see any announcement on the list about downtime, so I guess this
is unintentional?

-andy

From reneschouten@seldi.nl Thu May 19 09:09:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 May 2005 09:10:07 +0100 (BST)
Received: from smtp1.euronet.nl ([IPv6:::ffff:194.134.35.133]:30866 "EHLO
	smtp1.euronet.nl") by linux-mips.org with ESMTP id <S8225209AbVESIJw>;
	Thu, 19 May 2005 09:09:52 +0100
Received: from Rene (htm-c-e0ae.mxs.adsl.euronet.nl [81.68.254.174])
	by smtp1.euronet.nl (Postfix) with SMTP id 7DF6B67258
	for <linux-mips@linux-mips.org>; Thu, 19 May 2005 10:09:50 +0200 (MEST)
Message-ID: <002901c55c4a$2030ede0$0a21a8c0@Rene>
From:	=?iso-8859-1?Q?Ren=E9_Schouten?= <reneschouten@seldi.nl>
To:	<linux-mips@linux-mips.org>
Subject: compiling pcmcia utils for mips
Date:	Thu, 19 May 2005 10:09:48 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2527
Return-Path: <reneschouten@seldi.nl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7930
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: reneschouten@seldi.nl
Precedence: bulk
X-list: linux-mips

Hi,

I want to enable pcmcia on a mips32 processor

I do have everything exept the cardmgr and cardctl programs that should be 
in the /sbin directory

I downloaded the pcmcia-cs-3.2.8.tar.tar., and i'm able to compile it with 
the standard compiler, but i'm not able to build "cardctl" and "cardmgr" 
with the crosscomipler.

My question: Can somebody give a link on where i can download the 2 files 
already compiled, or tell me what to change in the "pcmcia-cs-3.2.8.tar.tar" 
files for only compiling the two utilitis with a cross compiler?

René 


From bruno.randolf@4g-systems.biz Thu May 19 09:39:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 May 2005 09:40:05 +0100 (BST)
Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:23818 "EHLO
	grey.subnet.at") by linux-mips.org with ESMTP id <S8225935AbVESIjs>;
	Thu, 19 May 2005 09:39:48 +0100
Received: from ip6-localhost ([193.170.141.4]) by grey.subnet.at ; Thu, 19 May 2005 10:39:35 +0200
From:	Bruno Randolf <bruno.randolf@4g-systems.biz>
To:	=?iso-8859-1?q?Ren=E9_Schouten?= <reneschouten@seldi.nl>
Subject: Re: compiling pcmcia utils for mips
Date:	Thu, 19 May 2005 10:39:25 +0200
User-Agent: KMail/1.7.2
References: <002901c55c4a$2030ede0$0a21a8c0@Rene>
In-Reply-To: <002901c55c4a$2030ede0$0a21a8c0@Rene>
Cc:	linux-mips@linux-mips.org
Organization: 4G Systems
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1406222.oERCYD85rN";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200505191039.29859.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7931
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips

--nextPart1406222.oERCYD85rN
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi rene!

you could check how it is done in openembedded:

http://openembedded.bkbits.net:8080/openembedded/src/packages/pcmcia-cs?nav=
=3Dindex.html|
src/.|src/packages

this one works for me.

bruno

On Thursday 19 May 2005 10:09, you wrote:
> Hi,
>
> I want to enable pcmcia on a mips32 processor
>
> I do have everything exept the cardmgr and cardctl programs that should be
> in the /sbin directory
>
> I downloaded the pcmcia-cs-3.2.8.tar.tar., and i'm able to compile it with
> the standard compiler, but i'm not able to build "cardctl" and "cardmgr"
> with the crosscomipler.
>
> My question: Can somebody give a link on where i can download the 2 files
> already compiled, or tell me what to change in the
> "pcmcia-cs-3.2.8.tar.tar" files for only compiling the two utilitis with a
> cross compiler?
>
> Ren=E9

--nextPart1406222.oERCYD85rN
Content-Type: application/pgp-signature

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

iD8DBQBCjFDBfg2jtUL97G4RAo8aAJ0VEhnkzx++ydqyRWjCRNPA1BbfmwCeOl+u
Ar6uFfOKXuTF3pln8oLgD4I=
=IxvI
-----END PGP SIGNATURE-----

--nextPart1406222.oERCYD85rN--

From belamina1@yahoo.com Thu May 19 14:52:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 May 2005 14:52:36 +0100 (BST)
Received: from web32510.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.220]:12475
	"HELO web32510.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225991AbVESNwP>; Thu, 19 May 2005 14:52:15 +0100
Received: (qmail 7763 invoked by uid 60001); 19 May 2005 13:52:07 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=lXetiXazeGIiuYQK8Elb0KEwflTD5c23jCuDBo9kFVAY7dMemAkPo0mmDZlQES8ed+jB+pEBE2QcbzFc6rXIdb4WUPuYA+mp2qW1J5jfXMOUboYBp25GtndLNO1xp84eIoU8BW8/mugBSBh7Qr9mIpC7Jv5i9QBldhnoyDKmVu4=  ;
Message-ID: <20050519135207.7760.qmail@web32510.mail.mud.yahoo.com>
Received: from [85.250.113.238] by web32510.mail.mud.yahoo.com via HTTP; Thu, 19 May 2005 06:52:07 PDT
Date:	Thu, 19 May 2005 06:52:07 -0700 (PDT)
From:	Michael Belamina <belamina1@yahoo.com>
Subject: Re: 64 bit kernel for BCM1250
To:	David Daney <ddaney@avtrex.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Michael Belamina <belamina1@yahoo.com>, linux-mips@linux-mips.org
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <belamina1@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7932
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belamina1@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

   Thanks very much for your replies and the valuable
info. 
   I am still not sure about the following:

   1. Is this problem related only to kernels
downloaded from linux-mips.org or it is a more general
one?

   2. Can someone point to a known to work 64 bit
versions of gcc and binutil for BCM1250 (the problem
that started this thread was actually a problem of the
mip64-linux-ld I was using).
    
Thanks,
 Michael



--- David Daney <ddaney@avtrex.com> wrote:
> Maciej W. Rozycki wrote:
> > On Wed, 18 May 2005, David Daney wrote:
> > 
> > 
> >>I saw this with a 32 bit kernel (for a 32 bit
> target).  As far as I know, no
> >>2.4.x kernels from linux-mips.org will work with
> gcc 3.4.x.
> > 
> > 
> >  That could actually be true -- I've been using
> GCC 4.0.0 for quite some 
> > time now (that includes CVS snapshots from before
> the release), so I have 
> > no slightest idea whether it's OK to use older
> versions. ;-)
> > 
> > 
> >>I have previously posted patches to this list that
> fixed the problem for me.
> >>Specifically I think the messages in this thread
> are relevant:
> >>
>
>>http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=41AFDA18.2010906%40avtrex.com
> > 
> > 
> >  Hasn't one of the proposed fixes for the bug made
> its way to Linux in the 
> > end?  That would be regrettable...
> > 
> 
> WRT the 2.4 kernel the answer seems to be no.  And
> yes I think it is 
> regrettable.
> 
> If anybody thinks it would be useful, I could post
> my current patch again.
> 
> David Daney.
> 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

From macro@linux-mips.org Thu May 19 16:19:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 May 2005 16:19:36 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:65039 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225993AbVESPTO>; Thu, 19 May 2005 16:19:14 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1A817F59E5; Thu, 19 May 2005 17:19: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 02322-02; Thu, 19 May 2005 17:19:03 +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 BEE41F5945; Thu, 19 May 2005 17:19: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.1/8.13.1) with ESMTP id j4JFJ6UX022822;
	Thu, 19 May 2005 17:19:06 +0200
Date:	Thu, 19 May 2005 16:19:14 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Michael Belamina <belamina1@yahoo.com>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
Subject: Re: 64 bit kernel for BCM1250
In-Reply-To: <20050519135207.7760.qmail@web32510.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61L.0505191605350.10681@blysk.ds.pg.gda.pl>
References: <20050519135207.7760.qmail@web32510.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/886/Wed May 18 12:32:36 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7933
X-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 Thu, 19 May 2005, Michael Belamina wrote:

>    I am still not sure about the following:
> 
>    1. Is this problem related only to kernels
> downloaded from linux-mips.org or it is a more general
> one?

 The problem is Linux 2.4 is generally in the maintenance mode, which 
means no new development is done on it (although still an occasional 
backport from 2.6 may happen).  As a result maintainers are rather 
hesitant about applying changes unless they fix critical bugs.  Bugs 
revealed by new versions of build tools are not usually considered as 
critical, because you may work them around by using an old version of the 
triggering tool.

 Still for the MIPS port what you can get from linux-mips.org is probably 
less behind than what there is at kernel.org.

>    2. Can someone point to a known to work 64 bit
> versions of gcc and binutil for BCM1250 (the problem
> that started this thread was actually a problem of the
> mip64-linux-ld I was using).

 For 64-bit builds you probably want to use fairly recent versions or you 
risk hitting serious bugs that used to exist in older versions.  Using 
David's patch (or preferably mine ;-) -- as available here: 
"http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.55.0406281509170.23162%40jurand.ds.pg.gda.pl"; 
which I keep using with GCC 4.0.0) is probably the lesser evil.

  Maciej

From ralf@linux-mips.org Thu May 19 16:27:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 May 2005 16:28:00 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:14878 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225999AbVESP1p>; Thu, 19 May 2005 16:27:45 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4JFRXOr007762;
	Thu, 19 May 2005 16:27:33 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4JFRWqL007761;
	Thu, 19 May 2005 16:27:32 +0100
Date:	Thu, 19 May 2005 16:27:32 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: remove obsolete serial setup
Message-ID: <20050519152732.GA26592@linux-mips.org>
References: <20050508233343.211ae78f.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050508233343.211ae78f.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7934
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, May 08, 2005 at 11:33:43PM +0900, Yoichi Yuasa wrote:

> This patch had removed obsolete serial setup for vr41xx.
> New vr41xx serial driver is included in 2.6.12-rc3.

Applied,

  Ralf

From ralf@linux-mips.org Thu May 19 16:43:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 May 2005 16:43:36 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:12806 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225999AbVESPnN>; Thu, 19 May 2005 16:43:13 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4JFh33P013950;
	Thu, 19 May 2005 16:43:03 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4JFh2ri013949;
	Thu, 19 May 2005 16:43:02 +0100
Date:	Thu, 19 May 2005 16:43:02 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: remove old TB0219 driver
Message-ID: <20050519154302.GB26592@linux-mips.org>
References: <20050513222528.010b2a4d.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050513222528.010b2a4d.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7935
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, May 13, 2005 at 10:25:28PM +0900, Yoichi Yuasa wrote:

> This patch had removed old TB0219 driver.

Applied.  Thanks Yoichi,

 Ralf

From jerry@wicomtechnologies.com Fri May 20 08:35:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 May 2005 08:35:48 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:4042
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8226006AbVETHfc>; Fri, 20 May 2005 08:35:32 +0100
Received: from jerry (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j4K7ZEwK093124;
	Fri, 20 May 2005 10:35:14 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Fri, 20 May 2005 10:36:55 +0300
From:	"Ruslan V.Pisarev" <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: "Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Organization: Home
X-Priority: 3 (Normal)
Message-ID: <1604819837.20050520103655@wicomtechnologies.com>
To:	Pete Popov <ppopov@embeddedalley.com>
CC:	linux-mips <linux-mips@linux-mips.org>
Subject: Re[2]: au1200 status
In-Reply-To: <1116341942.5802.15.camel@localhost.localdomain>
References: <1547700103.20050517142217@izmiran.rssi.ru>
 <1116341942.5802.15.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7936
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips

>[In reply to "au1200 status" from Pete Popov <ppopov@embeddedalley.com> to Ruslan V.Pisarev <jerry@izmiran.rssi.ru>  17/05/2005 17:59]

PP> The Au1200 support will from migrate from 2.4 to 2.6 when either someone
PP> funds the effort or someone has time to do it for fun.

err .. Even noone has in plans to do it ?


   ()_()
--( ^,^ )---[21398845]- -<The Bat! 3.0.1.33>- -<20/05/2005 10:33>-
  (") (")


From jerry@izmiran.rssi.ru Fri May 20 10:19:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 May 2005 10:19:44 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:8138
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8226374AbVETJT3>; Fri, 20 May 2005 10:19:29 +0100
Received: from jerry (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j4K9JIwK093571;
	Fri, 20 May 2005 12:19:18 +0300 (EEST)
	(envelope-from jerry@izmiran.rssi.ru)
Date:	Fri, 20 May 2005 12:20:59 +0300
From:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: "Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
Organization: Home
X-Priority: 3 (Normal)
Message-ID: <17280353.20050520122059@wicomtechnologies.com>
To:	Pete Popov <ppopov@embeddedalley.com>
CC:	linux-mips <linux-mips@linux-mips.org>
Subject: Re[2]: au1200 status
In-Reply-To: <1116341942.5802.15.camel@localhost.localdomain>
References: <1547700103.20050517142217@izmiran.rssi.ru>
 <1116341942.5802.15.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@izmiran.rssi.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7937
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@izmiran.rssi.ru
Precedence: bulk
X-list: linux-mips

>[In reply to "au1200 status" from Pete Popov <ppopov@embeddedalley.com> to Ruslan V.Pisarev <jerry@izmiran.rssi.ru>  17/05/2005 17:59]

PP> The Au1200 support will from migrate from 2.4 to 2.6 when either someone
PP> funds the effort or someone has time to do it for fun.

  A few thoughts in addition.. At my point of view, au1200 support is
a big mess now. Some companies (AMD, Montawisra, etc) released their
kernels which are not fully synch-ed nor with 2.4 tree at linux-mips
nor with 2.6 one nor with each other. Therefore we forced to "sit and
stay" on one of these old and undeveloped projects (especially most of
them are commercial product (I think even if we'll need a good stable
commercial product - we buy windows :)) or do the same job - make this
all creepy stuff to work on last released kernel. (which will be
replaced after some months with analoguis but better one from amd,
mwista, mr.Jones, mrs.Addams, etc..)
  Have you any ideas about this?



   ()_()
--( ^,^ )---[21398845]- -<The Bat! 3.0.1.33>- -<20/05/2005 11:42>-
  (") (")


From thomas.koeller@baslerweb.com Fri May 20 14:24:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 May 2005 14:24:34 +0100 (BST)
Received: from mail.baslerweb.com ([IPv6:::ffff:145.253.187.130]:21221 "EHLO
	mail.baslerweb.com") by linux-mips.org with ESMTP
	id <S8226391AbVETNYR>; Fri, 20 May 2005 14:24:17 +0100
Received: (from mail@localhost)
	by mail.baslerweb.com (8.12.10/8.12.10) id j4KDOfe0005540
	for <linux-mips@linux-mips.org>; Fri, 20 May 2005 15:24:41 +0200
Received: from unknown by gateway id /var/KryptoWall/smtpp/kwuqYR6S; Fri May 20 15:24:24 2005
Received: from vclinux-1.basler.corp (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id KW3LV1QA; Fri, 20 May 2005 15:23:53 +0200
From:	Thomas Koeller <thomas.koeller@baslerweb.com>
Organization: Basler AG
To:	"Linux/MIPS Development" <linux-mips@linux-mips.org>,
	linux-kernel@vger.kernel.org
Subject: vmap() problem, possible bug?
Date:	Fri, 20 May 2005 15:23:52 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Message-Id: <200505201523.52194.thomas.koeller@baslerweb.com>
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-Path: <thomas.koeller@baslerweb.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7938
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: thomas.koeller@baslerweb.com
Precedence: bulk
X-list: linux-mips

Hi,

writing a device driver I came across something that looks
to me like a bug in the vmap() function. I am using kernel
2.6.11-rc1 (from linux-mips.org cvs, but the problem is
probably not mips-specific).

My driver transfers large amounts of data using DMA to a
buffer passed in from userland and translated to a page
list via get_user_pages(). Due to alignment restrictions
imposed by the DMA hardware, I have to use a temporary
buffer page for a part of the data buffer, and to copy
the data from this page to the actual buffer using
memcpy(). To be able to to so, I am using vmap() to create
a temporary mapping for the part of the buffer where the
data is to be copied, do the copy, and then call vunmap()
to remove the mapping:



if (pkt->copy_size) {
	const unsigned int page_order =
		(pkt->copy_size > PAGE_SIZE) ? 1 : 0;
	void * const dst = vmap(pkt->copy_pg, 0x1 << page_order,
				VM_MAP, PAGE_USERIO);

	if (dst) {
		memcpy(dst + pkt->copy_offs, pkt->copy_src,
		       pkt->copy_size);
		free_pages((unsigned long) pkt->copy_src, page_order);
		vunmap(dst);
	} else {
		pkt->pset->status = XICAP_BUFSTAT_VMERR;
	}
}



The code above is executed once for every data buffer
processed. It works as expected most of the time, but
every once in a while the data copied is not written to
the correct location, but to the previously processed
buffer instead. It looks as if the mapping established
for that buffer had survived the vunmap() / vmap() sequence.

In case it matters, my system is single core (not SMP).
Any ideas, anybody?

tk
-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

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

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


From dan@embeddededge.com Fri May 20 15:37:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 May 2005 15:38:00 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:7178 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226405AbVETOho>; Fri, 20 May 2005 15:37:44 +0100
Received: from [192.168.2.27] (h69-21-252-132.69-21.unk.tds.net [69.21.252.132])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j4KETUfg005343;
	Fri, 20 May 2005 10:29:30 -0400
In-Reply-To: <17280353.20050520122059@wicomtechnologies.com>
References: <1547700103.20050517142217@izmiran.rssi.ru> <1116341942.5802.15.camel@localhost.localdomain> <17280353.20050520122059@wicomtechnologies.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b0afb7d1d448436c15e94b90a87f10f1@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips <linux-mips@linux-mips.org>,
	Pete Popov <ppopov@embeddedalley.com>
From:	Dan Malek <dan@embeddededge.com>
Subject: Re: Re[2]: au1200 status
Date:	Fri, 20 May 2005 10:37:43 -0400
To:	"Ruslan V.Pisarev" <jerry@izmiran.rssi.ru>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddededge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7939
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@embeddededge.com
Precedence: bulk
X-list: linux-mips


On May 20, 2005, at 5:20 AM, Ruslan V.Pisarev wrote:

>   Have you any ideas about this?

You can do what the rest of us have been doing for years.
If you don't like it, take the time to fix it and submit the updates.
Although it is nice to get this for free and some people actually
get paid to work on it, some of us have spent countless hours
of our own time providing what you see today.  Step up and
help or stop complaining.

If you have actually paid for software from one of the
commercial vendors you mentioned, work with their support
staff to get your problems resolved.

Thanks.


	-- Dan


From yuasa@hh.iij4u.or.jp Sun May 22 03:14:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 May 2005 03:14:40 +0100 (BST)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:3282 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225227AbVEVCOW>;
	Sun, 22 May 2005 03:14:22 +0100
Received: MO(mo00)id j4M2EH1C016842; Sun, 22 May 2005 11:14:17 +0900 (JST)
Received: MDO(mdo01) id j4M2EHsf014623; Sun, 22 May 2005 11:14:17 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j4M2EETW009206
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Sun, 22 May 2005 11:14:16 +0900 (JST)
Date:	Sun, 22 May 2005 11:14:13 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: add resource management to pmu
Message-Id: <20050522111413.2ad36681.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7940
X-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,

This patch had added resource management to vr41xx's pmu.
Please apply.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff rc4-orig/arch/mips/vr41xx/common/pmu.c rc4/arch/mips/vr41xx/common/pmu.c
--- rc4-orig/arch/mips/vr41xx/common/pmu.c	Sat May  7 14:20:31 2005
+++ rc4/arch/mips/vr41xx/common/pmu.c	Sun May 15 18:14:50 2005
@@ -1,7 +1,7 @@
 /*
  *  pmu.c, Power Management Unit routines for NEC VR4100 series.
  *
- *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *  Copyright (C) 2003-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -17,7 +17,9 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <linux/smp.h>
 #include <linux/types.h>
@@ -27,20 +29,31 @@
 #include <asm/reboot.h>
 #include <asm/system.h>
 
-#define PMUCNT2REG	KSEG1ADDR(0x0f0000c6)
+#define PMU_TYPE1_BASE	0x0b0000a0UL
+#define PMU_TYPE1_SIZE	0x0eUL
+
+#define PMU_TYPE2_BASE	0x0f0000c0UL
+#define PMU_TYPE2_SIZE	0x10UL
+
+#define PMUCNT2REG	0x06
  #define SOFTRST	0x0010
 
+static void __iomem *pmu_base;
+
+#define pmu_read(offset)		readw(pmu_base + (offset))
+#define pmu_write(offset, value)	writew((value), pmu_base + (offset))
+
 static inline void software_reset(void)
 {
-	uint16_t val;
+	uint16_t pmucnt2;
 
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		val = readw(PMUCNT2REG);
-		val |= SOFTRST;
-		writew(val, PMUCNT2REG);
+		pmucnt2 = pmu_read(PMUCNT2REG);
+		pmucnt2 |= SOFTRST;
+		pmu_write(PMUCNT2REG, pmucnt2);
 		break;
 	default:
 		break;
@@ -71,6 +84,34 @@
 
 static int __init vr41xx_pmu_init(void)
 {
+	unsigned long start, size;
+
+	switch (current_cpu_data.cputype) {
+	case CPU_VR4111:
+	case CPU_VR4121:
+		start = PMU_TYPE1_BASE;
+		size = PMU_TYPE1_SIZE;
+		break;
+	case CPU_VR4122:
+	case CPU_VR4131:
+	case CPU_VR4133:
+		start = PMU_TYPE2_BASE;
+		size = PMU_TYPE2_SIZE;
+		break;
+	default:
+		printk("Unexpected CPU of NEC VR4100 series\n");
+		return -ENODEV;
+	}
+
+	if (request_mem_region(start, size, "PMU") == NULL)
+		return -EBUSY;
+
+	pmu_base = ioremap(start, size);
+	if (pmu_base == NULL) {
+		release_mem_region(start, size);
+		return -EBUSY;
+	}
+
 	_machine_restart = vr41xx_restart;
 	_machine_halt = vr41xx_halt;
 	_machine_power_off = vr41xx_power_off;
@@ -78,4 +119,4 @@
 	return 0;
 }
 
-early_initcall(vr41xx_pmu_init);
+core_initcall(vr41xx_pmu_init);



From yuasa@hh.iij4u.or.jp Sun May 22 03:20:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 May 2005 03:20:52 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:12246 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225234AbVEVCUh>;
	Sun, 22 May 2005 03:20:37 +0100
Received: MO(mo01)id j4M2KWCl010683; Sun, 22 May 2005 11:20:32 +0900 (JST)
Received: MDO(mdo00) id j4M2KWZk007392; Sun, 22 May 2005 11:20:32 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j4M2KVk8013775
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Sun, 22 May 2005 11:20:31 +0900 (JST)
Date:	Sun, 22 May 2005 11:20:30 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: update setup functions
Message-Id: <20050522112030.59e103ec.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7941
X-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,

This patch had updated vr41xx setup functions.
o add __init
o change from early_initcall to arch_initcall

Please apply.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff b-orig/arch/mips/vr41xx/casio-e55/setup.c b/arch/mips/vr41xx/casio-e55/setup.c
--- b-orig/arch/mips/vr41xx/casio-e55/setup.c	Sat Apr 23 22:59:07 2005
+++ b/arch/mips/vr41xx/casio-e55/setup.c	Sat Apr 23 23:32:33 2005
@@ -17,6 +17,7 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include <linux/init.h>
 #include <linux/ioport.h>
 
 #include <asm/io.h>
@@ -27,7 +28,7 @@
 	return "CASIO CASSIOPEIA E-11/15/55/65";
 }
 
-static int casio_e55_setup(void)
+static int __init casio_e55_setup(void)
 {
 	set_io_port_base(IO_PORT_BASE);
 	ioport_resource.start = IO_PORT_RESOURCE_START;
@@ -36,4 +37,4 @@
 	return 0;
 }
 
-early_initcall(casio_e55_setup);
+arch_initcall(casio_e55_setup);
diff -urN -X dontdiff b-orig/arch/mips/vr41xx/ibm-workpad/setup.c b/arch/mips/vr41xx/ibm-workpad/setup.c
--- b-orig/arch/mips/vr41xx/ibm-workpad/setup.c	Sat Apr 23 22:59:08 2005
+++ b/arch/mips/vr41xx/ibm-workpad/setup.c	Sat Apr 23 23:32:33 2005
@@ -17,6 +17,7 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include <linux/init.h>
 #include <linux/ioport.h>
 
 #include <asm/io.h>
@@ -27,7 +28,7 @@
 	return "IBM WorkPad z50";
 }
 
-static int ibm_workpad_setup(void)
+static int __init ibm_workpad_setup(void)
 {
 	set_io_port_base(IO_PORT_BASE);
 	ioport_resource.start = IO_PORT_RESOURCE_START;
@@ -36,4 +37,4 @@
 	return 0;
 }
 
-early_initcall(ibm_workpad_setup);
+arch_initcall(ibm_workpad_setup);

From belamina1@yahoo.com Sun May 22 21:31:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 May 2005 21:32:12 +0100 (BST)
Received: from web32515.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.225]:16766
	"HELO web32515.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225002AbVEVUby>; Sun, 22 May 2005 21:31:54 +0100
Received: (qmail 24630 invoked by uid 60001); 22 May 2005 20:31:46 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=jtAqPDI3rbSfflz3tRYrCVGQCmm9WeG9x1GafKlKH/RXvFhYYIMRdshgGJkbb9Yy7puSb4JmxBYqostgXn2SUFdqfaxp+x2T5C72tcTOoUSWUZWGSvcE2zh3MPblZ1azMraeCcMN4AyaPikiVU0qpBkI0nt4MUzAZOy4GpLsoSU=  ;
Message-ID: <20050522203146.24628.qmail@web32515.mail.mud.yahoo.com>
Received: from [217.132.151.249] by web32515.mail.mud.yahoo.com via HTTP; Sun, 22 May 2005 13:31:46 PDT
Date:	Sun, 22 May 2005 13:31:46 -0700 (PDT)
From:	Michael Belamina <belamina1@yahoo.com>
Subject: Re: 64 bit kernel for BCM1250
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <belamina1@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7942
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belamina1@yahoo.com
Precedence: bulk
X-list: linux-mips


  Thanks you all for your replies.
  I will check this out and post the outcome.

 Michael

  


--- "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> On Thu, 19 May 2005, Michael Belamina wrote:
> 
> >    I am still not sure about the following:
> > 
> >    1. Is this problem related only to kernels
> > downloaded from linux-mips.org or it is a more
> general
> > one?
> 
>  The problem is Linux 2.4 is generally in the
> maintenance mode, which 
> means no new development is done on it (although
> still an occasional 
> backport from 2.6 may happen).  As a result
> maintainers are rather 
> hesitant about applying changes unless they fix
> critical bugs.  Bugs 
> revealed by new versions of build tools are not
> usually considered as 
> critical, because you may work them around by using
> an old version of the 
> triggering tool.
> 
>  Still for the MIPS port what you can get from
> linux-mips.org is probably 
> less behind than what there is at kernel.org.
> 
> >    2. Can someone point to a known to work 64 bit
> > versions of gcc and binutil for BCM1250 (the
> problem
> > that started this thread was actually a problem of
> the
> > mip64-linux-ld I was using).
> 
>  For 64-bit builds you probably want to use fairly
> recent versions or you 
> risk hitting serious bugs that used to exist in
> older versions.  Using 
> David's patch (or preferably mine ;-) -- as
> available here: 
>
"http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.55.0406281509170.23162%40jurand.ds.pg.gda.pl";
> 
> which I keep using with GCC 4.0.0) is probably the
> lesser evil.
> 
>   Maciej
> 


		
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


From sskowron@ET.PUT.Poznan.PL Mon May 23 08:10:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 08:10:49 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:64153 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225240AbVEWHKd>; Mon, 23 May 2005 08:10:33 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4N7ARe06007
	for <linux-mips@linux-mips.org>; Mon, 23 May 2005 09:10:28 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 23 May 2005 09:10:27 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4N7APx04407
	for <linux-mips@linux-mips.org>; Mon, 23 May 2005 09:10:26 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Mon, 23 May 2005 09:10:25 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	linux-mips@linux-mips.org
Subject: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
Message-ID: <Pine.GSO.4.10.10505230905300.4132-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7943
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

Hi!

It seems that gcc (with -O; -O0 fixes the issue) will generate R_MIPS_HI16
without succeeding R_MIPS_LO16 (or the other way - but it's not a real
problem that way) in '.rel.text' (not '.rela.text'). According to SGI ELF
spec this combination is invalid (well, addend AHL is created from low 16
bits from HI16 and low 16 bits from LO16, and the actual result of
relocation might depend on the LO16 part - at least this is what I
understood from the specific[a]tion); it also upsets Indy PROM when
converted into ECOFF.

Gcc 3.4.3 does not exhibit this (wanton) behavior. What the heck?

Stanislaw Skowronek

--<=>--
  "There is no pain, you are receding...
   A distant ship, smoke on the horizon.
   You are only coming through in waves,
   Your lips move, but I can't hear what you're saying."



From ralf@linux-mips.org Mon May 23 12:09:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 12:10:14 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:54285 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225538AbVEWLJ7>; Mon, 23 May 2005 12:09:59 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4NB9US5006326;
	Mon, 23 May 2005 12:09:30 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4NB9TIn006325;
	Mon, 23 May 2005 12:09:29 +0100
Date:	Mon, 23 May 2005 12:09:28 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: add resource management to pmu
Message-ID: <20050523110928.GA6319@linux-mips.org>
References: <20050522111413.2ad36681.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050522111413.2ad36681.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7944
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, May 22, 2005 at 11:14:13AM +0900, Yoichi Yuasa wrote:

> This patch had added resource management to vr41xx's pmu.
> Please apply.

Applied,

  Ralf

From ralf@linux-mips.org Mon May 23 12:15:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 12:15:34 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:27913 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225547AbVEWLPS>; Mon, 23 May 2005 12:15:18 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4NBEpFC006542;
	Mon, 23 May 2005 12:14:51 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4NBEpED006541;
	Mon, 23 May 2005 12:14:51 +0100
Date:	Mon, 23 May 2005 12:14:51 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: update setup functions
Message-ID: <20050523111451.GA4383@linux-mips.org>
References: <20050522112030.59e103ec.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050522112030.59e103ec.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7945
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, May 22, 2005 at 11:20:30AM +0900, Yoichi Yuasa wrote:

> This patch had updated vr41xx setup functions.
> o add __init
> o change from early_initcall to arch_initcall

Applied,

  Ralf

From rsandifo@redhat.com Mon May 23 12:17:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 12:18:11 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:45506 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225544AbVEWLRz>;
	Mon, 23 May 2005 12:17:55 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4NBHpcO021288;
	Mon, 23 May 2005 07:17:51 -0400
Received: from firetop.home (vpn50-11.rdu.redhat.com [172.16.50.11])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4NBHoO09935;
	Mon, 23 May 2005 07:17:50 -0400
Received: from rsandifo by firetop.home with local (Exim 4.50)
	id 1DaAwK-0002Ok-Fp; Mon, 23 May 2005 12:17:44 +0100
From:	Richard Sandiford <rsandifo@redhat.com>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
References: <Pine.GSO.4.10.10505230905300.4132-100000@helios.et.put.poznan.pl>
Date:	Mon, 23 May 2005 12:17:44 +0100
In-Reply-To: <Pine.GSO.4.10.10505230905300.4132-100000@helios.et.put.poznan.pl>
	(Stanislaw Skowronek's message of "Mon, 23 May 2005 09:10:25 +0200
	(MET DST)")
Message-ID: <87oeb26vjb.fsf@firetop.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7946
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> writes:
> It seems that gcc (with -O; -O0 fixes the issue) will generate R_MIPS_HI16
> without succeeding R_MIPS_LO16 (or the other way - but it's not a real
> problem that way) in '.rel.text' (not '.rela.text'). According to SGI ELF
> spec this combination is invalid (well, addend AHL is created from low 16
> bits from HI16 and low 16 bits from LO16, and the actual result of
> relocation might depend on the LO16 part - at least this is what I
> understood from the specific[a]tion); it also upsets Indy PROM when
> converted into ECOFF.
>
> Gcc 3.4.3 does not exhibit this (wanton) behavior. What the heck?

Remember that support for %hi() and %lo() on REL targets is a GNU extension.
The assembler is expected to reorder the relocations so that the HI16s
come before the LO16s.  It sounds like this isn't happening in your case,
so which version of binutils are you using?

This isn't really a change from gcc 3.4 to "gcc 3.5" (now known as 4.0 ;).
It has long been possible for gcc's assembly code to contain "out of order"
%hi()s and %lo()s.  On the other hand, the more aggressive the optimisers
are, the more likely you are to see it, so the behaviour will certainly
be different in specific testcases.

Richard

From toch@dfpost.ru Mon May 23 15:44:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 15:44:44 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:35021 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225749AbVEWOo3>;
	Mon, 23 May 2005 15:44:29 +0100
Received: by mail.dfpost.ru (Postfix, from userid 7897)
	id 3332A3E457; Mon, 23 May 2005 18:42:16 +0400 (MSD)
Received: from toch.dfpost.ru (toch [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id B99883E455
	for <linux-mips@linux-mips.org>; Mon, 23 May 2005 18:42:14 +0400 (MSD)
Date:	Mon, 23 May 2005 18:45:01 +0400
From:	Dmitriy Tochansky <toch@dfpost.ru>
To:	linux-mips@linux-mips.org
Subject: yenta_socket
Message-Id: <20050523184501.3e733eb3.toch@dfpost.ru>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.92.8
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7947
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Hi!

Cant get where is the problem.

Look. I have pci->pcmcia cardbus adaptor CP3-HOUSE and I want to start it on mips.

Im enable cardbus yenta type in kernel config and see the follow:

Yenta: CardBus bridge found at 0000:00:11.0 [e4bf:2000]                         
yenta 0000:00:11.0: Preassigned resource 0 busy, reconfiguring...               
yenta 0000:00:11.0: Preassigned resource 1 busy, reconfiguring...               
Yenta: Enabling burst memory read transactions                                  
Yenta: Using CSCINT to route CSC interrupts to PCI                              
Yenta: Routing CardBus interrupts to PCI                                        
Yenta TI: socket 0000:00:11.0, mfunc 0x0fc01d02, devctl 0x66                    
drivers/pcmcia/ti113x.h pci_irq_status = 0                                      
Yenta TI: socket 0000:00:11.0 probing PCI interrupt failed, trying to fix       
Yenta TI: socket 0000:00:11.0 falling back to parallel PCI interrupts           
Yenta TI: socket 0000:00:11.0 no PCI interrupts. Fish. Please report.           
CPU 0 Unable to handle kernel paging request at virtual address 00000004, epc =0
....

As far I understand driver cant get irq for this card but when I disable
this driver I can see(via cat /proc/pci) that cardbus have irq 4... :(
Ideas\advices are wellcome!

-- 
Dmitriy Tochansky
toch@dfpost.ru
JID: dtoch@jabber.ru

From jerry@wicomtechnologies.com Mon May 23 16:07:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 16:07:33 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:52416
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8225747AbVEWPHO>; Mon, 23 May 2005 16:07:14 +0100
Received: from jerry (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j4NF6v5K002964;
	Mon, 23 May 2005 18:06:58 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Mon, 23 May 2005 18:08:19 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <1371154543.20050523180819@wicomtechnologies.com>
To:	David Daney <ddaney@avtrex.com>
CC:	linux-mips <linux-mips@linux-mips.org>
Subject: Re[2]: 64 bit kernel for BCM1250
In-Reply-To: <428B6EDD.4040508@avtrex.com>
References: <20050518080917.45521.qmail@web32501.mail.mud.yahoo.com>
 <428B663C.7050308@avtrex.com>
 <Pine.LNX.4.61L.0505181715070.19170@blysk.ds.pg.gda.pl>
 <428B6EDD.4040508@avtrex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7948
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips

Hello David,
Wednesday, May 18, 2005, 7:35:41 PM, you wrote:

>>>I saw this with a 32 bit kernel (for a 32 bit target).  As far as I
>>>know, no 2.4.x kernels from linux-mips.org will work with gcc
>>>3.4.x.
>>  That could actually be true -- I've been using GCC 4.0.0 for quite
>> some time now (that includes CVS snapshots from before the
>> release), so I have no slightest idea whether it's OK to use older
>> versions. ;-)
>>>I have previously posted patches to this list that fixed the
>>>problem for me. Specifically I think the messages in this thread
>>>are relevant:
>>>http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=41AFDA18.2010906%40avtrex.com
>>  Hasn't one of the proposed fixes for the bug made its way to Linux
>> in the end?  That would be regrettable...
> WRT the 2.4 kernel the answer seems to be no.  And yes I think it is
> regrettable. If anybody thinks it would be useful, I could post my
> current patch again.

 Hmm right now I see the same result with oops caused
new_inode(pipe_mnt->mnt_sb) where pipe_mnt=0 witn 2.4 kernels and
gcc3.4.3 on dbau1200. If there was any changes in patch since Dec2004,
and if it hepls to solve this problem - can you please repost it
again?



   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.0.1.33>- -<23/05/2005 18:03>-
  (") (")


From jerry@wicomtechnologies.com Mon May 23 16:24:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 16:25:09 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:54976
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8225751AbVEWPYy>; Mon, 23 May 2005 16:24:54 +0100
Received: from jerry (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j4NFOl5K003045;
	Mon, 23 May 2005 18:24:47 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Mon, 23 May 2005 18:26:09 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <27582192.20050523182609@wicomtechnologies.com>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
CC:	linux-mips <linux-mips@linux-mips.org>
Subject: Re[2]: 64 bit kernel for BCM1250
In-Reply-To: <Pine.LNX.4.61L.0505191605350.10681@blysk.ds.pg.gda.pl>
References: <20050519135207.7760.qmail@web32510.mail.mud.yahoo.com>
 <Pine.LNX.4.61L.0505191605350.10681@blysk.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7949
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips

Hello Maciej,
Thursday, May 19, 2005, 6:19:14 PM, you wrote:

>  For 64-bit builds you probably want to use fairly recent versions or you
> risk hitting serious bugs that used to exist in older versions.  Using
> David's patch (or preferably mine ;-) -- as available here: 
> "http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.55.0406281509170.23162%40jurand.ds.pg.gda.pl";
> which I keep using with GCC 4.0.0) is probably the lesser evil.

 Without going into details - what difference between your and David's
patch ? :) I'm in doubts which one is more suitable for me...


   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.0.1.33>- -<23/05/2005 18:18>-
  (") (")


From ddaney@avtrex.com Mon May 23 16:39:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 16:39:43 +0100 (BST)
Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:61811
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225764AbVEWPj1>;
	Mon, 23 May 2005 16:39:27 +0100
Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 23 May 2005 08:39:24 -0700
Message-ID: <4291F929.9000302@avtrex.com>
Date:	Mon, 23 May 2005 08:39:21 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Jerry <jerry@wicomtechnologies.com>
CC:	"Maciej W. Rozycki" <macro@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: 64 bit kernel for BCM1250
References: <20050519135207.7760.qmail@web32510.mail.mud.yahoo.com> <Pine.LNX.4.61L.0505191605350.10681@blysk.ds.pg.gda.pl> <27582192.20050523182609@wicomtechnologies.com>
In-Reply-To: <27582192.20050523182609@wicomtechnologies.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 May 2005 15:39:24.0108 (UTC) FILETIME=[986B58C0:01C55FAD]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7950
X-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

Jerry wrote:
> Hello Maciej,
> Thursday, May 19, 2005, 6:19:14 PM, you wrote:
> 
> 
>> For 64-bit builds you probably want to use fairly recent versions or you
>>risk hitting serious bugs that used to exist in older versions.  Using
>>David's patch (or preferably mine ;-) -- as available here: 
>>"http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.55.0406281509170.23162%40jurand.ds.pg.gda.pl";
>>which I keep using with GCC 4.0.0) is probably the lesser evil.
> 
> 
>  Without going into details - what difference between your and David's
> patch ? :) I'm in doubts which one is more suitable for me...
> 

FWIW: My current patch is quite similar to Maciej's.

David Daney.

From anemo@mba.ocn.ne.jp Mon May 23 16:52:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 16:52:18 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:62445 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225781AbVEWPwD>; Mon, 23 May 2005 16:52:03 +0100
Received: from localhost (p6118-ipad205funabasi.chiba.ocn.ne.jp [222.146.101.118])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id DEDC084F4
	for <linux-mips@linux-mips.org>; Tue, 24 May 2005 00:51:59 +0900 (JST)
Date:	Tue, 24 May 2005 00:54:47 +0900 (JST)
Message-Id: <20050524.005447.96686952.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Subject: Re: yenta_socket
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050523184501.3e733eb3.toch@dfpost.ru>
References: <20050523184501.3e733eb3.toch@dfpost.ru>
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: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7951
X-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 Mon, 23 May 2005 18:45:01 +0400, Dmitriy Tochansky <toch@dfpost.ru> said:

toch> Im enable cardbus yenta type in kernel config and see the
toch> follow:

toch> yenta 0000:00:11.0: Preassigned resource 0 busy, reconfiguring...
toch> yenta 0000:00:11.0: Preassigned resource 1 busy, reconfiguring...

I think these messages are due to confliction with resource management
codes in drivers/pci/setup-bus.c.  Though I do not see details yet,
this quick workaround might solve this issue.

--- linux-mips/drivers/pcmcia/yenta_socket.c	2005-04-18 00:43:34.000000000 +0900
+++ linux/drivers/pcmcia/yenta_socket.c	2005-05-04 00:21:38.000000000 +0900
@@ -611,10 +611,12 @@
  */
 static void yenta_allocate_resources(struct yenta_socket *socket)
 {
+#if 0
 	yenta_allocate_res(socket, 0, IORESOURCE_MEM|IORESOURCE_PREFETCH);
 	yenta_allocate_res(socket, 1, IORESOURCE_MEM);
 	yenta_allocate_res(socket, 2, IORESOURCE_IO);
 	yenta_allocate_res(socket, 3, IORESOURCE_IO);	/* PCI isn't clever enough to use this one yet */
+#endif
 }
 
 
---
Atsushi Nemoto

From toch@dfpost.ru Mon May 23 17:18:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 17:18:32 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:44514 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225792AbVEWQSQ>;
	Mon, 23 May 2005 17:18:16 +0100
Received: by mail.dfpost.ru (Postfix, from userid 7897)
	id 2080D3E457; Mon, 23 May 2005 20:16:04 +0400 (MSD)
Received: from toch.dfpost.ru (toch [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id A27E93E455
	for <linux-mips@linux-mips.org>; Mon, 23 May 2005 20:16:03 +0400 (MSD)
Date:	Mon, 23 May 2005 20:18:48 +0400
From:	Dmitriy Tochansky <toch@dfpost.ru>
To:	linux-mips@linux-mips.org
Subject: Re: yenta_socket
Message-Id: <20050523201848.3dd58338.toch@dfpost.ru>
In-Reply-To: <20050524.005447.96686952.anemo@mba.ocn.ne.jp>
References: <20050523184501.3e733eb3.toch@dfpost.ru>
	<20050524.005447.96686952.anemo@mba.ocn.ne.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.92.8
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7952
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

On Tue, 24 May 2005 00:54:47 +0900 (JST)
Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:

> >>>>> On Mon, 23 May 2005 18:45:01 +0400, Dmitriy Tochansky <toch@dfpost.ru> said:
> 
> toch> Im enable cardbus yenta type in kernel config and see the
> toch> follow:
> 
> toch> yenta 0000:00:11.0: Preassigned resource 0 busy, reconfiguring...
> toch> yenta 0000:00:11.0: Preassigned resource 1 busy, reconfiguring...
> 
> I think these messages are due to confliction with resource management
> codes in drivers/pci/setup-bus.c.  Though I do not see details yet,
> this quick workaround might solve this issue.
> 
> --- linux-mips/drivers/pcmcia/yenta_socket.c	2005-04-18 00:43:34.000000000 +0900
> +++ linux/drivers/pcmcia/yenta_socket.c	2005-05-04 00:21:38.000000000 +0900
> @@ -611,10 +611,12 @@
  
  Well, yes, the resourse problem "dissapear", but irq is still asking to report. I'll try to check setup-bus.c becourse IMHO there is problem in irq assignment or something.
Yenta: CardBus bridge found at 0000:00:11.0 [e4bf:2000]                         
Yenta: Enabling burst memory read transactions                                  
Yenta: Using CSCINT to route CSC interrupts to PCI                              
Yenta: Routing CardBus interrupts to PCI                                        
Yenta TI: socket 0000:00:11.0, mfunc 0x0fc01d02, devctl 0x66                    
drivers/pcmcia/ti113x.h pci_irq_status = 0                                      
Yenta TI: socket 0000:00:11.0 probing PCI interrupt failed, trying to fix       
Yenta TI: socket 0000:00:11.0 falling back to parallel PCI interrupts           
Yenta TI: socket 0000:00:11.0 no PCI interrupts. Fish. Please report.           
CPU 0 Unable to handle kernel paging request at virtual address 00000004, epc =c
Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:                      


-- 
Dmitriy Tochansky
toch@dfpost.ru
JID: dtoch@jabber.ru

From sskowron@ET.PUT.Poznan.PL Mon May 23 17:19:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 17:20:01 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:43693
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225795AbVEWQTp>; Mon, 23 May 2005 17:19:45 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4NGJh222761;
	Mon, 23 May 2005 18:19:43 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 23 May 2005 18:19:43 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4NGJgW04720;
	Mon, 23 May 2005 18:19:42 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Mon, 23 May 2005 18:19:42 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Richard Sandiford <rsandifo@redhat.com>
cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <87oeb26vjb.fsf@firetop.home>
Message-ID: <Pine.GSO.4.10.10505231802070.3392-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7953
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> Remember that support for %hi() and %lo() on REL targets is a GNU extension.

Erm. Are you sure?

SGI's ELF64 spec says:

"Any of the relocation types may appear in either a SHT_REL or a SHT_RELA
relocation section, except that relocation types involving AHL operands
are forbidden in a 64-bit SHT_REL section and discouraged in a 32-bit
SHT_REL section."

There is no word of GNU there and in any case SGI had their own tools. But
again, it is possible that the idea bounced back and forth...

> The assembler is expected to reorder the relocations so that the HI16s
> come before the LO16s.  It sounds like this isn't happening in your case,
> so which version of binutils are you using?

The user who sent the b0rked binary (`K) uses 2.15.94 or so (I'll ask him
again) / "gcc 3.5". On 2.15 / gcc 3.4.3 there is no problem like this (at
least I can't trigger it).

> This isn't really a change from gcc 3.4 to "gcc 3.5" (now known as 4.0 ;).

Well, one of %hi()s is reordered to beginning of a loop and this is what
makes it unpaired. I don't think that any assembler could fix that.

Thanks for answering,

Stanislaw




From toch@dfpost.ru Mon May 23 17:24:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 17:25:05 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:16869 "EHLO
	mail.dfpost.ru") by linux-mips.org with ESMTP id <S8225797AbVEWQYv>;
	Mon, 23 May 2005 17:24:51 +0100
Received: by mail.dfpost.ru (Postfix, from userid 7897)
	id 92C163E457; Mon, 23 May 2005 20:22:27 +0400 (MSD)
Received: from toch.dfpost.ru (toch [192.168.7.60])
	by mail.dfpost.ru (Postfix) with SMTP id 3901E3E455
	for <linux-mips@linux-mips.org>; Mon, 23 May 2005 20:22:27 +0400 (MSD)
Date:	Mon, 23 May 2005 20:25:14 +0400
From:	Dmitriy Tochansky <toch@dfpost.ru>
To:	linux-mips@linux-mips.org
Subject: Re: yenta_socket
Message-Id: <20050523202514.3d97d1b5.toch@dfpost.ru>
In-Reply-To: <20050523184501.3e733eb3.toch@dfpost.ru>
References: <20050523184501.3e733eb3.toch@dfpost.ru>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.92.8
Return-Path: <toch@dfpost.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7954
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

On Mon, 23 May 2005 18:45:01 +0400
Dmitriy Tochansky <toch@dfpost.ru> wrote:

> Yenta: CardBus bridge found at 0000:00:11.0 [e4bf:2000]                         
> yenta 0000:00:11.0: Preassigned resource 0 busy, reconfiguring...               
> yenta 0000:00:11.0: Preassigned resource 1 busy, reconfiguring...               
> Yenta: Enabling burst memory read transactions                                  
> Yenta: Using CSCINT to route CSC interrupts to PCI                              
> Yenta: Routing CardBus interrupts to PCI                                        
> Yenta TI: socket 0000:00:11.0, mfunc 0x0fc01d02, devctl 0x66                    
> drivers/pcmcia/ti113x.h pci_irq_status = 0                                      
> Yenta TI: socket 0000:00:11.0 probing PCI interrupt failed, trying to fix       
> Yenta TI: socket 0000:00:11.0 falling back to parallel PCI interrupts           
> Yenta TI: socket 0000:00:11.0 no PCI interrupts. Fish. Please report.           
> CPU 0 Unable to handle kernel paging request at virtual address 00000004, epc =0
> ....

Hm... Bus 5?

Linux Kernel Card Services                                                      
  options:  [pci] [cardbus]                                                     
PCI: Bus 1, cardbus bridge: 0000:00:11.0                                        
  IO window: 00001000-00001fff                                                  
  IO window: 00002000-00002fff                                                  
  PREFETCH window: 40000000-41ffffff                                            
  MEM window: 42000000-43ffffff                                                 
PCI: Bus 5, cardbus bridge: 0000:00:11.1                                        
  IO window: 00003000-00003fff                                                  
  IO window: 00004000-00004fff                                                  
  PREFETCH window: 44000000-45ffffff                                            
  MEM window: 46000000-47ffffff                                                 
PCI: Enabling device 0000:00:11.0 (0000 -> 0002)                                
PCI: Enabling device 0000:00:11.1 (0000 -> 0002)                                


-- 
Dmitriy Tochansky
toch@dfpost.ru
JID: dtoch@jabber.ru

From rsandifo@redhat.com Mon May 23 18:23:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 18:23:46 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:25047 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225808AbVEWRX3>;
	Mon, 23 May 2005 18:23:29 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4NHNO3C019218;
	Mon, 23 May 2005 13:23:24 -0400
Received: from firetop.home (vpn50-36.rdu.redhat.com [172.16.50.36])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4NHNNO23720;
	Mon, 23 May 2005 13:23:24 -0400
Received: from rsandifo by firetop.home with local (Exim 4.50)
	id 1DaGe5-0003IL-RR; Mon, 23 May 2005 18:23:17 +0100
From:	Richard Sandiford <rsandifo@redhat.com>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
References: <87oeb26vjb.fsf@firetop.home>
	<Pine.GSO.4.10.10505231802070.3392-100000@helios.et.put.poznan.pl>
Date:	Mon, 23 May 2005 18:23:17 +0100
In-Reply-To: <Pine.GSO.4.10.10505231802070.3392-100000@helios.et.put.poznan.pl>
	(Stanislaw Skowronek's message of "Mon, 23 May 2005 18:19:42 +0200
	(MET DST)")
Message-ID: <8764x926wq.fsf@firetop.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7955
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> writes:
>> Remember that support for %hi() and %lo() on REL targets is a GNU extension.
>
> Erm. Are you sure?
>
> SGI's ELF64 spec says:
>
> "Any of the relocation types may appear in either a SHT_REL or a SHT_RELA
> relocation section, except that relocation types involving AHL operands
> are forbidden in a 64-bit SHT_REL section and discouraged in a 32-bit
> SHT_REL section."
>
> There is no word of GNU there and in any case SGI had their own tools. But
> again, it is possible that the idea bounced back and forth...

I'm talking about the %hi() and %lo() relocation _operators_,
not the ELF relocations themselves.  The ELF spec has nothing
to say about the syntax of assembler relocation operators.

>> This isn't really a change from gcc 3.4 to "gcc 3.5" (now known as 4.0 ;).
>
> Well, one of %hi()s is reordered to beginning of a loop and this is what
> makes it unpaired. I don't think that any assembler could fix that.

What do you mean?  I'm talking about reordering the relocations in
the .rel.foo section, not reordering the code.  I.e. if you have:

    .text
    ...
    addiu $4,$4,%lo(foo)
    ...
    lui $4,%hi(foo)

the assembler is expected to output the R_MIPS_HI16 .rel.text entry
for the lui before the R_MIPS_LO16 entry for the addiu.

Richard

From sskowron@ET.PUT.Poznan.PL Mon May 23 18:32:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 May 2005 18:32:22 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:61373
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225825AbVEWRcE>; Mon, 23 May 2005 18:32:04 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4NHW2223549;
	Mon, 23 May 2005 19:32:02 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 23 May 2005 19:32:01 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4NHW0909155;
	Mon, 23 May 2005 19:32:00 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Mon, 23 May 2005 19:32:00 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Richard Sandiford <rsandifo@redhat.com>
cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <8764x926wq.fsf@firetop.home>
Message-ID: <Pine.GSO.4.10.10505231928030.8910-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7956
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> I'm talking about the %hi() and %lo() relocation _operators_,
> not the ELF relocations themselves.  The ELF spec has nothing
> to say about the syntax of assembler relocation operators.

OK, right :)

> What do you mean?  I'm talking about reordering the relocations in
> the .rel.foo section, not reordering the code.  I.e. if you have:
> 
>     .text
>     ...
>     addiu $4,$4,%lo(foo)
>     ...
>     lui $4,%hi(foo)
> 
> the assembler is expected to output the R_MIPS_HI16 .rel.text entry
> for the lui before the R_MIPS_LO16 entry for the addiu.

If you have something like that:

	.text
	...
loop_label:
	lui $4, %hi(foo)
	addiu $4, $4, %lo(foo)
	...
	jmp loop_label
	...

the compiler might be smart and change it into:

	.text
	...
	lui $4, %hi(foo)
loop_label:
	addiu $4, $4, %lo(foo)
	...
	lui $4, %hi(foo)
	jmp loop_label
	...

for instance, to put the lui into branch delay slot (quite a smart
decision, this one). However now %hi and %lo are unpaired. What should the
tool do?

Cheers,

Stanislaw



From rsandifo@redhat.com Tue May 24 07:35:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 07:35:59 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:49600 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224970AbVEXGfo>;
	Tue, 24 May 2005 07:35:44 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4O6ZdSO018138;
	Tue, 24 May 2005 02:35:39 -0400
Received: from firetop.home (vpn50-30.rdu.redhat.com [172.16.50.30])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4O6ZcO01197;
	Tue, 24 May 2005 02:35:38 -0400
Received: from rsandifo by firetop.home with local (Exim 4.50)
	id 1DaT0m-00012p-C4; Tue, 24 May 2005 07:35:32 +0100
From:	Richard Sandiford <rsandifo@redhat.com>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
References: <8764x926wq.fsf@firetop.home>
	<Pine.GSO.4.10.10505231928030.8910-100000@helios.et.put.poznan.pl>
Date:	Tue, 24 May 2005 07:35:32 +0100
In-Reply-To: <Pine.GSO.4.10.10505231928030.8910-100000@helios.et.put.poznan.pl>
	(Stanislaw Skowronek's message of "Mon, 23 May 2005 19:32:00 +0200
	(MET DST)")
Message-ID: <87ekbx872j.fsf@firetop.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7957
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> writes:
>> What do you mean?  I'm talking about reordering the relocations in
>> the .rel.foo section, not reordering the code.  I.e. if you have:
>> 
>>     .text
>>     ...
>>     addiu $4,$4,%lo(foo)
>>     ...
>>     lui $4,%hi(foo)
>> 
>> the assembler is expected to output the R_MIPS_HI16 .rel.text entry
>> for the lui before the R_MIPS_LO16 entry for the addiu.
>
> If you have something like that:
>
> 	.text
> 	...
> loop_label:
> 	lui $4, %hi(foo)
> 	addiu $4, $4, %lo(foo)
> 	...
> 	jmp loop_label
> 	...
>
> the compiler might be smart and change it into:
>
> 	.text
> 	...
> 	lui $4, %hi(foo)
> loop_label:
> 	addiu $4, $4, %lo(foo)
> 	...
> 	lui $4, %hi(foo)
> 	jmp loop_label
> 	...
>
> for instance, to put the lui into branch delay slot (quite a smart
> decision, this one). However now %hi and %lo are unpaired. What should the
> tool do?

It should generate:

    R_MIPS_HI16
    R_MIPS_HI16
    R_MIPS_LO16

And yes, the idea that several HI16s can be associated with the same
LO16 is also a GNU extension. ;)

(FWIW: as before, this extension, and indeed the whole idea of "out of
order" or "unpaired" %hi()s, isn't new.  It's been around for 10 years.)

Richard

From sskowron@ET.PUT.Poznan.PL Tue May 24 07:39:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 07:39:32 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:49575
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224970AbVEXGjS>; Tue, 24 May 2005 07:39:18 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4O6dF202088;
	Tue, 24 May 2005 08:39:15 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 24 May 2005 08:39:14 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4O6dED12795;
	Tue, 24 May 2005 08:39:14 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Tue, 24 May 2005 08:39:14 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Richard Sandiford <rsandifo@redhat.com>
cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <87ekbx872j.fsf@firetop.home>
Message-ID: <Pine.GSO.4.10.10505240837530.12717-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7958
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> It should generate:
> 
>     R_MIPS_HI16
>     R_MIPS_HI16
>     R_MIPS_LO16
> 
> And yes, the idea that several HI16s can be associated with the same
> LO16 is also a GNU extension. ;)

Good, no problem - thanks for confirming my darkest suspicions. How can I
detect this? (I've got to emit SGI-compliant ECOFF.) I can emit sham
relocs into .rel.text that point into specially added synthetic
instructions.

Stanislaw



From rsandifo@redhat.com Tue May 24 07:56:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 07:57:06 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:48586 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8224970AbVEXG4v>;
	Tue, 24 May 2005 07:56:51 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4O6ulVw023580;
	Tue, 24 May 2005 02:56:47 -0400
Received: from firetop.home (vpn50-30.rdu.redhat.com [172.16.50.30])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4O6ugO04623;
	Tue, 24 May 2005 02:56:42 -0400
Received: from rsandifo by firetop.home with local (Exim 4.50)
	id 1DaTL9-00012s-Uk; Tue, 24 May 2005 07:56:35 +0100
From:	Richard Sandiford <rsandifo@redhat.com>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
References: <Pine.GSO.4.10.10505240837530.12717-100000@helios.et.put.poznan.pl>
Date:	Tue, 24 May 2005 07:56:35 +0100
In-Reply-To: <Pine.GSO.4.10.10505240837530.12717-100000@helios.et.put.poznan.pl>
	(Stanislaw Skowronek's message of "Tue, 24 May 2005 08:39:14 +0200
	(MET DST)")
Message-ID: <87acml863g.fsf@firetop.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7959
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> writes:

>> It should generate:
>> 
>>     R_MIPS_HI16
>>     R_MIPS_HI16
>>     R_MIPS_LO16
>> 
>> And yes, the idea that several HI16s can be associated with the same
>> LO16 is also a GNU extension. ;)
>
> Good, no problem - thanks for confirming my darkest suspicions. How can I
> detect this? (I've got to emit SGI-compliant ECOFF.) I can emit sham
> relocs into .rel.text that point into specially added synthetic
> instructions.

Sorry if this is a dumb question, but why do you need to generate
_relocatable_ ECOFF?  If you really need to do that, I think you'll
just have to force gcc to use assembler macros, ala:

   gcc -mno-explicit-relocs -mno-split-addresses

Richard

From sskowron@ET.PUT.Poznan.PL Tue May 24 07:58:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 07:58:59 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:10207 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224970AbVEXG6o>; Tue, 24 May 2005 07:58:44 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4O6wee20160;
	Tue, 24 May 2005 08:58:41 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 24 May 2005 08:58:39 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4O6wbm13747;
	Tue, 24 May 2005 08:58:38 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Tue, 24 May 2005 08:58:37 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Richard Sandiford <rsandifo@redhat.com>
cc:	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <87acml863g.fsf@firetop.home>
Message-ID: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7960
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> Sorry if this is a dumb question, but why do you need to generate
> _relocatable_ ECOFF?

It allows me to boot all Indys and O2s off the same binary. Nice for boot
CDs. Especially that Octanes and Origins should be bootable from another
one... just like IRIX.

> If you really need to do that, I think you'll just have to force gcc
> to use assembler macros, ala:
> 
>    gcc -mno-explicit-relocs -mno-split-addresses

Thanks!

Stanislaw



From macro@linux-mips.org Tue May 24 11:41:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 11:41:41 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:10249 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbVEXKlZ>; Tue, 24 May 2005 11:41:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id EB3BDF5998; Tue, 24 May 2005 12:41:15 +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 30746-02; Tue, 24 May 2005 12:41:15 +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 9212CF5997; Tue, 24 May 2005 12:41:15 +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.1/8.13.1) with ESMTP id j4OAemYW016137;
	Tue, 24 May 2005 12:40:48 +0200
Date:	Tue, 24 May 2005 11:40:53 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 19:52:19 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7961
X-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, 24 May 2005, Stanislaw Skowronek wrote:

> > Sorry if this is a dumb question, but why do you need to generate
> > _relocatable_ ECOFF?
> 
> It allows me to boot all Indys and O2s off the same binary. Nice for boot
> CDs. Especially that Octanes and Origins should be bootable from another
> one... just like IRIX.

 Do they use a different load address so that you keep an "almost fully 
linked" relocatable (i.e. with all objects already included, but still 
done with "-r") and do the final link differently for each of them?  If 
this is the case you should be able to keep that "almost fully linked" 
relocatable as ELF and then just do the final link using ELF and then 
`objcopy' to ECOFF.  That should work for most of the cases, although I've 
seen problems with firmware not recognizing MIPS III ECOFF binaries 
expecting a MIPS I one instead.  AFAIK, `objcopy' doesn't allow you to 
force a different magic number upon a conversion -- this is probably the 
last reason `elf2ecoff' hasn't been removed from the Linux tree yet (and 
you can use the tool indeed if you hit this problem).

 Trying to support GNU extensions in ECOFF is probably hopeless and not 
worth the hassle and the file format is likely to be obsoleted by the 
toolchain soon (if not already done), except from BFD -- which'll let you 
continue doing `objcopy', `objdump', etc.

  Maciej

From rsandifo@redhat.com Tue May 24 11:50:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 11:50:54 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:59108 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225198AbVEXKuj>;
	Tue, 24 May 2005 11:50:39 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4OAoOGx032132;
	Tue, 24 May 2005 06:50:24 -0400
Received: from firetop.home (vpn50-30.rdu.redhat.com [172.16.50.30])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4OAoNO22734;
	Tue, 24 May 2005 06:50:23 -0400
Received: from rsandifo by firetop.home with local (Exim 4.50)
	id 1DaWzJ-0001Zs-Bj; Tue, 24 May 2005 11:50:17 +0100
From:	Richard Sandiford <rsandifo@redhat.com>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl>
	<Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
Date:	Tue, 24 May 2005 11:50:17 +0100
In-Reply-To: <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl> (Maciej
	W. Rozycki's message of "Tue, 24 May 2005 11:40:53 +0100 (BST)")
Message-ID: <871x7w99ue.fsf@firetop.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7962
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>  Trying to support GNU extensions in ECOFF is probably hopeless and not 
> worth the hassle and the file format is likely to be obsoleted by the 
> toolchain soon (if not already done), except from BFD -- which'll let you 
> continue doing `objcopy', `objdump', etc.

Yeah.  It's probably also worth noting that we might (soon?) remove the
-mno-explicit-relocs/-mno-split-addresses mode from gcc.  Having both
modes does add to the maintenance burden and the gas support for PIC
relocation operators has been around for a while now.  (It dates back
to binutils 2.14 IIRC.)

Richard

From sskowron@ET.PUT.Poznan.PL Tue May 24 11:51:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 11:51:36 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:22249 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225205AbVEXKuo>; Tue, 24 May 2005 11:50:44 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4OAoce22132;
	Tue, 24 May 2005 12:50:39 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 24 May 2005 12:50:36 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4OAlQh25508;
	Tue, 24 May 2005 12:47:26 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Tue, 24 May 2005 12:47:26 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
cc:	Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7963
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> > It allows me to boot all Indys and O2s off the same binary. Nice for boot
> > CDs. Especially that Octanes and Origins should be bootable from another
> > one... just like IRIX.

>  Do they use a different load address so that you keep an "almost fully 
> linked" relocatable (i.e. with all objects already included, but still 
> done with "-r") and do the final link differently for each of them?

Yes, exactly.

> If this is the case you should be able to keep that "almost fully
> linked"  relocatable as ELF and then just do the final link using ELF
> and then `objcopy' to ECOFF.

I tried objcopy (it was my first thought), for one reason or another it
didn't work (internal BFD error something). Reportedly ECOFF is belly-up
in current GNU binutils - at least it is what I heard.

>  Trying to support GNU extensions in ECOFF is probably hopeless and not 
> worth the hassle and the file format is likely to be obsoleted by the 
> toolchain soon (if not already done), except from BFD -- which'll let you 
> continue doing `objcopy', `objdump', etc.

My input is elf32-tradbigmips. So I entirely don't care for binutils'
ECOFF anymore, and I consider this a good thing. As I said, objcopy didn't
work at all. Fixing BFD is not my job (it's a monster of Frankensteinian
proportions), I think that it is actually much easier to write my own
converter (well, I did it, and it works - except that funny HI/LO mismatch
I'm going to work around).

Stanislaw



From macro@linux-mips.org Tue May 24 12:41:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 12:42:06 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:12044 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225206AbVEXLlu>; Tue, 24 May 2005 12:41:50 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 700C0F599D; Tue, 24 May 2005 13:41:45 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 00606-03; Tue, 24 May 2005 13:41:45 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 359BBF5998; Tue, 24 May 2005 13:41:45 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id j4OBeL7S018589;
	Tue, 24 May 2005 13:40:22 +0200
Date:	Tue, 24 May 2005 12:40:28 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl>
Message-ID: <Pine.LNX.4.61L.0505241226400.13738@blysk.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/893/Tue May 24 08:27:20 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7964
X-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, 24 May 2005, Stanislaw Skowronek wrote:

> I tried objcopy (it was my first thought), for one reason or another it
> didn't work (internal BFD error something). Reportedly ECOFF is belly-up
> in current GNU binutils - at least it is what I heard.

 And the bug report is...  Well, where?

> My input is elf32-tradbigmips. So I entirely don't care for binutils'
> ECOFF anymore, and I consider this a good thing. As I said, objcopy didn't
> work at all. Fixing BFD is not my job (it's a monster of Frankensteinian
> proportions), I think that it is actually much easier to write my own
> converter (well, I did it, and it works - except that funny HI/LO mismatch
> I'm going to work around).

 Well, you are not required to fix BFD, but if you don't even report 
problems they are going to be left undiscovered forever...

  Maciej

From ralf@linux-mips.org Tue May 24 15:23:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 15:23:37 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:3598 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225256AbVEXOXW>; Tue, 24 May 2005 15:23:22 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4OEMken015970;
	Tue, 24 May 2005 15:22:46 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4OEMj44015969;
	Tue, 24 May 2005 15:22:45 +0100
Date:	Tue, 24 May 2005 15:22:45 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	Richard Sandiford <rsandifo@redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
Message-ID: <20050524142245.GG4383@linux-mips.org>
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl> <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7965
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, May 24, 2005 at 11:40:53AM +0100, Maciej W. Rozycki wrote:

> 
>  Do they use a different load address so that you keep an "almost fully 
> linked" relocatable (i.e. with all objects already included, but still 
> done with "-r") and do the final link differently for each of them?  If 
> this is the case you should be able to keep that "almost fully linked" 
> relocatable as ELF and then just do the final link using ELF and then 
> `objcopy' to ECOFF.  That should work for most of the cases, although I've 
> seen problems with firmware not recognizing MIPS III ECOFF binaries 
> expecting a MIPS I one instead.  AFAIK, `objcopy' doesn't allow you to 
> force a different magic number upon a conversion -- this is probably the 
> last reason `elf2ecoff' hasn't been removed from the Linux tree yet (and 
> you can use the tool indeed if you hit this problem).

The kernel ELF binary is too complicated for objcopy to cope with.  Fixing
objcopy to handle this case correctly turned out to be hopeless but with
a little linker script magic it's possible to keep the kernel vmlinux file
within what elf2ecoff can deal with.

>  Trying to support GNU extensions in ECOFF is probably hopeless and not 
> worth the hassle and the file format is likely to be obsoleted by the 
> toolchain soon (if not already done), except from BFD -- which'll let you 
> continue doing `objcopy', `objdump', etc.

If anything a real ECOFF toolchain would be needed.  Teaching ECOFF about
all the ELF magic like complex handling of certain magic symbols etc. is
a waste of time ...

  Ralf

From macro@linux-mips.org Tue May 24 15:50:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 15:50:42 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:8 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225264AbVEXOu0>; Tue, 24 May 2005 15:50:26 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 5CA00F59AA; Tue, 24 May 2005 16:50: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 20061-07; Tue, 24 May 2005 16:50: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 6E24EF599A; Tue, 24 May 2005 16:50:09 +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.1/8.13.1) with ESMTP id j4OEo7bD026969;
	Tue, 24 May 2005 16:50:07 +0200
Date:	Tue, 24 May 2005 15:50:16 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	Richard Sandiford <rsandifo@redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <20050524142245.GG4383@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0505241548330.13738@blysk.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl>
 <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
 <20050524142245.GG4383@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/893/Tue May 24 08:27:20 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7966
X-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, 24 May 2005, Ralf Baechle wrote:

> >  Do they use a different load address so that you keep an "almost fully 
> > linked" relocatable (i.e. with all objects already included, but still 
> > done with "-r") and do the final link differently for each of them?  If 
> > this is the case you should be able to keep that "almost fully linked" 
> > relocatable as ELF and then just do the final link using ELF and then 
> > `objcopy' to ECOFF.  That should work for most of the cases, although I've 
> > seen problems with firmware not recognizing MIPS III ECOFF binaries 
> > expecting a MIPS I one instead.  AFAIK, `objcopy' doesn't allow you to 
> > force a different magic number upon a conversion -- this is probably the 
> > last reason `elf2ecoff' hasn't been removed from the Linux tree yet (and 
> > you can use the tool indeed if you hit this problem).
> 
> The kernel ELF binary is too complicated for objcopy to cope with.  Fixing
> objcopy to handle this case correctly turned out to be hopeless but with
> a little linker script magic it's possible to keep the kernel vmlinux file
> within what elf2ecoff can deal with.

 Well, it used to work for me the few times I tried, except from that MIPS 
III magic number problem.  But that's not a binutils' fault.

  Maciej

From ralf@linux-mips.org Tue May 24 16:00:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 16:01:02 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:18187 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225271AbVEXPAo>; Tue, 24 May 2005 16:00:44 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4OF08cH016983;
	Tue, 24 May 2005 16:00:08 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4OF08YG016982;
	Tue, 24 May 2005 16:00:08 +0100
Date:	Tue, 24 May 2005 16:00:08 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	Richard Sandiford <rsandifo@redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
Message-ID: <20050524150008.GC13850@linux-mips.org>
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl> <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl> <20050524142245.GG4383@linux-mips.org> <Pine.LNX.4.61L.0505241548330.13738@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0505241548330.13738@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7967
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, May 24, 2005 at 03:50:16PM +0100, Maciej W. Rozycki wrote:

> > The kernel ELF binary is too complicated for objcopy to cope with.  Fixing
> > objcopy to handle this case correctly turned out to be hopeless but with
> > a little linker script magic it's possible to keep the kernel vmlinux file
> > within what elf2ecoff can deal with.
> 
>  Well, it used to work for me the few times I tried, except from that MIPS 
> III magic number problem.  But that's not a binutils' fault.

That's because you haven't booted 2.6 on DECstations yet ;-)  I'm sure
you'll have some elf2ecoff fun ...

  Ralf

From macro@linux-mips.org Tue May 24 16:04:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 16:04:31 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:45317 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225271AbVEXPEQ>; Tue, 24 May 2005 16:04:16 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 300D3F59AC; Tue, 24 May 2005 17:04: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 20423-09; Tue, 24 May 2005 17:04: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 E3AD5F59AA; Tue, 24 May 2005 17:04:10 +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.1/8.13.1) with ESMTP id j4OF4E2v027692;
	Tue, 24 May 2005 17:04:14 +0200
Date:	Tue, 24 May 2005 16:04:22 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	Richard Sandiford <rsandifo@redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
In-Reply-To: <20050524150008.GC13850@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0505241601200.13738@blysk.ds.pg.gda.pl>
References: <Pine.GSO.4.10.10505240857260.13676-100000@helios.et.put.poznan.pl>
 <Pine.LNX.4.61L.0505241122290.13738@blysk.ds.pg.gda.pl>
 <20050524142245.GG4383@linux-mips.org> <Pine.LNX.4.61L.0505241548330.13738@blysk.ds.pg.gda.pl>
 <20050524150008.GC13850@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/893/Tue May 24 08:27:20 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7968
X-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, 24 May 2005, Ralf Baechle wrote:

> >  Well, it used to work for me the few times I tried, except from that MIPS 
> > III magic number problem.  But that's not a binutils' fault.
> 
> That's because you haven't booted 2.6 on DECstations yet ;-)  I'm sure
> you'll have some elf2ecoff fun ...

 I won't unless I insist on checking -- my configuration doesn't need 
ECOFF.  It's never needed, actually, hence my lack of incentive in finding 
problems to fix with ECOFF. ;-)

  Maciej

From raghunathan.venkatesan@wipro.com Tue May 24 16:35:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 16:35:55 +0100 (BST)
Received: from wip-ec-wd.wipro.com ([IPv6:::ffff:203.101.113.39]:6865 "EHLO
	wip-ec-wd.wipro.com") by linux-mips.org with ESMTP
	id <S8225291AbVEXPfj>; Tue, 24 May 2005 16:35:39 +0100
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id E774C2051E
	for <linux-mips@linux-mips.org>; Tue, 24 May 2005 20:56:45 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (unknown [10.201.50.92])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id CE0572051D
	for <linux-mips@linux-mips.org>; Tue, 24 May 2005 20:56:45 +0530 (IST)
Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211);
	 Tue, 24 May 2005 21:05:28 +0530
Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 24 May 2005 21:05:11 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C56076.2CBC07F0"
Subject: Unable to handle kernel paging request at virtual address 04000460
Date:	Tue, 24 May 2005 21:02:06 +0530
Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0CF563C@CHN-SNR-MBX01.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unable to handle kernel paging request at virtual address 04000460
Thread-Index: AcVgdb3pII4bfpg6Saua9o/sQJUI4w==
From:	<raghunathan.venkatesan@wipro.com>
To:	<linux-mips@linux-mips.org>
X-OriginalArrivalTime: 24 May 2005 15:35:11.0726 (UTC) FILETIME=[2C66A8E0:01C56076]
Return-Path: <raghunathan.venkatesan@wipro.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7969
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raghunathan.venkatesan@wipro.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C56076.2CBC07F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
We are facing the following crash in custom Linux 2.4.26 kernel, when we
run a netperf TCP Stream (sizes varying from 64 to 32586 bytes) test
over an IPSEC tunnel created between a host and a VPN server through our
box. This is a Au1550 MIPS32 based board (DB1550 Cabernet board from
AMD). We observe that crash happens randomly (the PrId keeps changing at
each crash), because of burstiness in the netperf tool generated
traffic. Please look into the following capture below. I'd like some
help in debugging this issue. The same set of IPSEC drivers works fine
on a custom Linux 2.4.25 based kernel. Is there a patch that needs to be
applied for Linux 2.4.26 ?=20
=20
Unable to handle kernel paging request at virtual address 04000460, epc
=3D=3D 802501cc, 8Oops in fault.c::do_page_fault, line 206:

$0 : 00000000 1000fc00 00000000 00000001 00000000 8b5f61b2 04000460
00000000

$8 : 00000000 00000000 1a000a08 0301590f 8b37d9d8 00000000 8b37dbd0
aa85e405

$16: 8b6d4780 00000001 8b6d4780 c01ce2a8 00000040 803251c0 00000001
8b37dc80

$24: 00000002 2afcee20 8b37c000 8b37dbb0 00004031 c01ce108

Hi : 00000000

Lo : 00000002

epc : 802501cc Not tainted

Status: 1000fc03

Cause : 00800008

PrId : 03030200

Process l2tpd (pid: 304, stackpage=3D8b37c000)

Stack: 1000fc03 00000002 00000000 8b5f61b2 80335808 c01ce108 1a000a08

0301590f 8b37d9d8 00000000 80255920 80255884 803d9400 803251cc 0000002c

803251ec 80352c88 8b6d4280 00000008 00000001 80255c94 2afcee20 00000006

80325080 8b37c000 8b37dc38 00004031 80255e48 803d9400 803251cc 0000002d

803251ec 80255e48 80255e60 8011b368 8011b368 8026a9e0 8025f444 803252b0

803251ec ...

Call Trace: [<c01ce108>] [<80255920>] [<80255884>] [<80255c94>]
[<80255e48>]

[<80255e48>] [<80255e60>] [<8011b368>] [<8011b368>] [<8026a9e0>]
[<8025f444>]

[<8025601c>] [<80116d90>] [<8011687c>] [<8010101c>] [<8010133c>]
[<801012ec>]

[<8026a7b8>] [<802ca7c8>] [<80255d08>] [<802c9f54>] [<80255e48>]
[<801aab24>]

[<801a3dc4>] [<801aab24>] [<801334c4>] [<801a1ee4>] [<8014fe9c>]
[<8014fe80>]

[<8024c918>] [<801a01a0>] [<801a22f4>] [<8015076c>] [<80150638>]
[<80105f0c>]

[<801046ac>] [<80107688>]

Code: 8e06009c 10c0000e 24030001 <8cc20000> c0450000 00a32023 e0440000
1080fffc 0

Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing

=20

Any help in debugging is welcome.

Regards,

Raghu


------_=_NextPart_001_01C56076.2CBC07F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D484181715-24052005>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D484181715-24052005>We are =
facing the=20
following crash in custom Linux 2.4.26 kernel, when we run a =
netperf&nbsp;TCP=20
Stream (sizes varying from 64 to 32586 bytes)&nbsp;test over an IPSEC =
tunnel=20
created between a host and a VPN server through our box. This is a =
Au1550 MIPS32=20
based board (DB1550 Cabernet board from AMD). We observe that crash =
happens=20
randomly (the PrId keeps changing at each crash), because of burstiness =
in the=20
netperf tool generated traffic. </SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D484181715-24052005>Please look into the following capture below. =
I'd like=20
some help in debugging this issue. The same set of IPSEC drivers works =
fine on a=20
custom Linux 2.4.25 based kernel. Is there a patch that needs to be =
applied for=20
Linux 2.4.26 ? </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D484181715-24052005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D484181715-24052005>
<P><FONT face=3DArial size=3D2>Unable to handle kernel paging request at =
virtual=20
address 04000460, epc =3D=3D 802501cc, 8Oops in fault.c::do_page_fault, =
line=20
206:</FONT></P>
<P><FONT face=3DArial size=3D2>$0 : 00000000 1000fc00 00000000 00000001 =
00000000=20
8b5f61b2 04000460 00000000</FONT></P>
<P><FONT face=3DArial size=3D2>$8 : 00000000 00000000 1a000a08 0301590f =
8b37d9d8=20
00000000 8b37dbd0 aa85e405</FONT></P>
<P><FONT face=3DArial size=3D2>$16: 8b6d4780 00000001 8b6d4780 c01ce2a8 =
00000040=20
803251c0 00000001 8b37dc80</FONT></P>
<P><FONT face=3DArial size=3D2>$24: 00000002 2afcee20 8b37c000 8b37dbb0 =
00004031=20
c01ce108</FONT></P>
<P><FONT face=3DArial size=3D2>Hi : 00000000</FONT></P>
<P><FONT face=3DArial size=3D2>Lo : 00000002</FONT></P>
<P><FONT face=3DArial size=3D2>epc : 802501cc Not tainted</FONT></P>
<P><FONT face=3DArial size=3D2>Status: 1000fc03</FONT></P>
<P><FONT face=3DArial size=3D2>Cause : 00800008</FONT></P>
<P><FONT face=3DArial size=3D2>PrId : 03030200</FONT></P>
<P><FONT face=3DArial size=3D2>Process l2tpd (pid: 304,=20
stackpage=3D8b37c000)</FONT></P>
<P><FONT face=3DArial size=3D2>Stack: 1000fc03 00000002 00000000 =
8b5f61b2 80335808=20
c01ce108 1a000a08</FONT></P>
<P><FONT face=3DArial size=3D2>0301590f 8b37d9d8 00000000 80255920 =
80255884 803d9400=20
803251cc 0000002c</FONT></P>
<P><FONT face=3DArial size=3D2>803251ec 80352c88 8b6d4280 00000008 =
00000001 80255c94=20
2afcee20 00000006</FONT></P>
<P><FONT face=3DArial size=3D2>80325080 8b37c000 8b37dc38 00004031 =
80255e48 803d9400=20
803251cc 0000002d</FONT></P>
<P><FONT face=3DArial size=3D2>803251ec 80255e48 80255e60 8011b368 =
8011b368 8026a9e0=20
8025f444 803252b0</FONT></P>
<P><FONT face=3DArial size=3D2>803251ec ...</FONT></P>
<P><FONT face=3DArial size=3D2>Call Trace: [&lt;c01ce108&gt;] =
[&lt;80255920&gt;]=20
[&lt;80255884&gt;] [&lt;80255c94&gt;] [&lt;80255e48&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2>[&lt;80255e48&gt;] [&lt;80255e60&gt;]=20
[&lt;8011b368&gt;] [&lt;8011b368&gt;] [&lt;8026a9e0&gt;]=20
[&lt;8025f444&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2>[&lt;8025601c&gt;] [&lt;80116d90&gt;]=20
[&lt;8011687c&gt;] [&lt;8010101c&gt;] [&lt;8010133c&gt;]=20
[&lt;801012ec&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2>[&lt;8026a7b8&gt;] [&lt;802ca7c8&gt;]=20
[&lt;80255d08&gt;] [&lt;802c9f54&gt;] [&lt;80255e48&gt;]=20
[&lt;801aab24&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2>[&lt;801a3dc4&gt;] [&lt;801aab24&gt;]=20
[&lt;801334c4&gt;] [&lt;801a1ee4&gt;] [&lt;8014fe9c&gt;]=20
[&lt;8014fe80&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2>[&lt;8024c918&gt;] [&lt;801a01a0&gt;]=20
[&lt;801a22f4&gt;] [&lt;8015076c&gt;] [&lt;80150638&gt;]=20
[&lt;80105f0c&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2>[&lt;801046ac&gt;] =
[&lt;80107688&gt;]</FONT></P>
<P><FONT face=3DArial size=3D2></FONT></P>
<P><FONT face=3DArial size=3D2>Code: 8e06009c 10c0000e 24030001 =
&lt;8cc20000&gt;=20
c0450000 00a32023 e0440000 1080fffc 0</FONT></P>
<P><FONT face=3DArial size=3D2>Kernel panic: Aiee, killing interrupt=20
handler!</FONT></P>
<P><FONT face=3DArial size=3D2>In interrupt handler - not =
syncing</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><SPAN class=3D484181715-24052005><FONT face=3DArial size=3D2>Any help =
in debugging=20
is welcome.</FONT></SPAN></P>
<P><SPAN class=3D484181715-24052005><FONT face=3DArial=20
size=3D2>Regards,</FONT></SPAN></P>
<P><SPAN class=3D484181715-24052005></SPAN><SPAN =
class=3D484181715-24052005><FONT=20
face=3DArial =
size=3D2>Raghu</FONT></SPAN></P></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C56076.2CBC07F0--

From philippedeswert@scarlet.be Tue May 24 16:47:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 May 2005 16:47:55 +0100 (BST)
Received: from xizor.is.scarlet.be ([IPv6:::ffff:193.74.71.21]:59792 "EHLO
	xizor.is.scarlet.be") by linux-mips.org with ESMTP
	id <S8225291AbVEXPrh> convert rfc822-to-8bit; Tue, 24 May 2005 16:47:37 +0100
Received: from (everest.is.scarlet.be [193.74.71.40]) 
	by xizor.is.scarlet.be  with ESMTP id j4OFl1h19253; 
	Tue, 24 May 2005 17:47:01 +0200
Date:	Tue, 24 May 2005 16:47:02 +0100
Message-Id: <IH03UE$F4786E1557576A5F497FC95F9CBA3255@scarlet.be>
Subject: Re:Unable to handle kernel paging request at virtual address 04000460
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
From:	"Philippe De Swert" <philippedeswert@scarlet.be>
To:	"raghunathan\.venkatesan" <raghunathan.venkatesan@wipro.com>
Cc:	"linux-mips" <linux-mips@linux-mips.org>
X-XaM3-API-Version: 4.1 (B54)
X-type:	0
X-SenderIP: 195.144.76.34
Return-Path: <philippedeswert@scarlet.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-Envid: <IH03UE$F4786E1557576A5F497FC95F9CBA3255
Envelope-Id: <IH03UE$F4786E1557576A5F497FC95F9CBA3255
X-archive-position: 7970
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: philippedeswert@scarlet.be
Precedence: bulk
X-list: linux-mips

Decode this dump with ksymoops

See here:
http://freshmeat.net/projects/ksymoops/

This will help you discover in which function it is dying, on which offset in
your kernel code etc... Very helpful for debugging. (in 2.6 you can even
compile something alike in the kernel (kallsyms))


---------- Initial header -----------

> We are facing the following crash in custom Linux 2.4.26 kernel, when we
> run a netperf TCP Stream (sizes varying from 64 to 32586 bytes) test
> over an IPSEC tunnel created between a host and a VPN server through our
> box. This is a Au1550 MIPS32 based board (DB1550 Cabernet board from
> AMD). We observe that crash happens randomly (the PrId keeps changing at
> each crash), because of burstiness in the netperf tool generated
> traffic. Please look into the following capture below. I'd like some
> help in debugging this issue. The same set of IPSEC drivers works fine
> on a custom Linux 2.4.25 based kernel. Is there a patch that needs to be
> applied for Linux 2.4.26 ? 
>  
> Unable to handle kernel paging request at virtual address 04000460, epc
> == 802501cc, 8Oops in fault.c::do_page_fault, line 206:
> 
> $0 : 00000000 1000fc00 00000000 00000001 00000000 8b5f61b2 04000460
> 00000000
<SNIP> KERNEL DUMP

CHEERS,

Philippe
 
| Philippe De Swert       
|      
| Stag developer http://stag.mind.be/  
| Emdebian developer: http://www.emdebian.org  
|   
| Please do not send me documents in a closed 
| format.(*.doc,*.xls,*.ppt)    
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)    
| http://www.gnu.org/philosophy/no-word-attachments.html  

-------------------------------------------------------
NOTE! My email address is changing to ... @scarlet.be
Please make the necessary changes in your address book. 




From jerry@wicomtechnologies.com Wed May 25 09:50:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 May 2005 09:50:46 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:11714
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8225526AbVEYIu2> convert rfc822-to-8bit; Wed, 25 May 2005 09:50:28 +0100
Received: from jerry (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j4P8oK5K010714
	for <linux-mips@linux-mips.org>; Wed, 25 May 2005 11:50:21 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Wed, 25 May 2005 11:51:43 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <1399568766.20050525115143@wicomtechnologies.com>
To:	linux-mips <linux-mips@linux-mips.org>
Subject: relocation truncated to fit
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8BIT
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7971
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips


Hello.
I failed to compile 2.4 kernel with "sound" option, it fails on
command:

mipsel-linux-ld -m elf32ltsmip -G 0 -static -n -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o init/do_mounts.o \
        --start-group \
        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o arch/mips/pci/pci-core.o \
         drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o drivers/media/media.o \
        net/network.o \
        arch/mips/lib/lib.a /work/video/kernel/lib/lib.a arch/mips/au1000/pb1200/pb1200.o arch/mips/au1000/common/au1000.o \
        --end-group \
        -o vmlinux
drivers/sound/sounddrivers.o: In function `sound_insert_unit':
sound_core.c:(.text+0x1ac): undefined reference to `strcpy'
sound_core.c:(.text+0x1ac): relocation truncated to fit: R_MIPS_26 against `strcpy'
make[1]: *** [vmlinux] Îøèáêà 1
make[1]: Leaving directory `/work/video/kernel'
make: *** [vmlinux] Îøèáêà 2

It's not a "sound drivers" problem, howewer without it kernel compiles
and run succesfully. Seems like gcc/bunitils bug/feature. What have to
be done to eliminate this error?

GNU ld version 2.15.96 20050308
gcc version 3.4.3


   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.0.1.33>- -<25/05/2005 11:39>-
  (") (")


From ralf@linux-mips.org Wed May 25 11:49:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 May 2005 11:50:03 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:8207 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225532AbVEYKtt>; Wed, 25 May 2005 11:49:49 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4PAn6OA032259;
	Wed, 25 May 2005 11:49:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4PAn6aD032258;
	Wed, 25 May 2005 11:49:06 +0100
Date:	Wed, 25 May 2005 11:49:05 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Jerry <jerry@wicomtechnologies.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: relocation truncated to fit
Message-ID: <20050525104905.GI4383@linux-mips.org>
References: <1399568766.20050525115143@wicomtechnologies.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1399568766.20050525115143@wicomtechnologies.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7972
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, May 25, 2005 at 11:51:43AM +0300, Jerry wrote:

> drivers/sound/sounddrivers.o: In function `sound_insert_unit':
> sound_core.c:(.text+0x1ac): undefined reference to `strcpy'
> sound_core.c:(.text+0x1ac): relocation truncated to fit: R_MIPS_26 against `strcpy'
> make[1]: *** [vmlinux] Ошибка 1
> make[1]: Leaving directory `/work/video/kernel'
> make: *** [vmlinux] Ошибка 2
> 
> It's not a "sound drivers" problem, howewer without it kernel compiles
> and run succesfully. Seems like gcc/bunitils bug/feature. What have to
> be done to eliminate this error?
> 
> GNU ld version 2.15.96 20050308
> gcc version 3.4.3

Don't use gcc 3.4 to compile Linux 2.4.  It may work for some kernel
configurations but it will fail for others.

  Ralf

From kumba@gentoo.org Wed May 25 13:36:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 May 2005 13:36:53 +0100 (BST)
Received: from sccrmhc14.comcast.net ([IPv6:::ffff:204.127.202.59]:25275 "EHLO
	sccrmhc14.comcast.net") by linux-mips.org with ESMTP
	id <S8224977AbVEYMgh>; Wed, 25 May 2005 13:36:37 +0100
Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45])
          by comcast.net (sccrmhc14) with ESMTP
          id <2005052512362901400i90g9e>; Wed, 25 May 2005 12:36:30 +0000
Message-ID: <429471EE.3090307@gentoo.org>
Date:	Wed, 25 May 2005 08:39:10 -0400
From:	Kumba <kumba@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Jerry <jerry@wicomtechnologies.com>
CC:	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: relocation truncated to fit
References: <1399568766.20050525115143@wicomtechnologies.com> <20050525104905.GI4383@linux-mips.org>
In-Reply-To: <20050525104905.GI4383@linux-mips.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7973
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> On Wed, May 25, 2005 at 11:51:43AM +0300, Jerry wrote:
> 
> 
>>drivers/sound/sounddrivers.o: In function `sound_insert_unit':
>>sound_core.c:(.text+0x1ac): undefined reference to `strcpy'
>>sound_core.c:(.text+0x1ac): relocation truncated to fit: R_MIPS_26 against `strcpy'
>>make[1]: *** [vmlinux] Ошибка 1
>>make[1]: Leaving directory `/work/video/kernel'
>>make: *** [vmlinux] Ошибка 2
>>
>>It's not a "sound drivers" problem, howewer without it kernel compiles
>>and run succesfully. Seems like gcc/bunitils bug/feature. What have to
>>be done to eliminate this error?
>>
>>GNU ld version 2.15.96 20050308
>>gcc version 3.4.3
> 
> 
> Don't use gcc 3.4 to compile Linux 2.4.  It may work for some kernel
> configurations but it will fail for others.
> 
>   Ralf

I would've thought this was fixed in 2.4.x now.  You might try using newer 
sources.  The below patch fixes the issue:

http://dev.gentoo.org/~kumba/tmp/gcc-strcpy-fix.patch


As the original patch I found stated about gcc-3.4.x:

From: Jan Hubicka <jh@suse.cz>

GCC now converts sprintf (a,"%s",b) to strcpy.  This lose on kernel as
strcpy is not inlined and not present in library, so one gets linker
failure.  It seems to make sense to apply this optimization by hand.


--Kumba

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

From ralf@linux-mips.org Wed May 25 14:08:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 May 2005 14:08:41 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:53010 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225242AbVEYNIZ>; Wed, 25 May 2005 14:08:25 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4PD7fi7004212;
	Wed, 25 May 2005 14:07:41 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4PD7fjs004211;
	Wed, 25 May 2005 14:07:41 +0100
Date:	Wed, 25 May 2005 14:07:41 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Kumba <kumba@gentoo.org>
Cc:	Jerry <jerry@wicomtechnologies.com>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: relocation truncated to fit
Message-ID: <20050525130741.GK4383@linux-mips.org>
References: <1399568766.20050525115143@wicomtechnologies.com> <20050525104905.GI4383@linux-mips.org> <429471EE.3090307@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <429471EE.3090307@gentoo.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7974
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, May 25, 2005 at 08:39:10AM -0400, Kumba wrote:
> Date:	Wed, 25 May 2005 08:39:10 -0400
> From:	Kumba <kumba@gentoo.org>
> To:	Jerry <jerry@wicomtechnologies.com>
> CC:	Ralf Baechle <ralf@linux-mips.org>,
> 	linux-mips <linux-mips@linux-mips.org>
> Subject: Re: relocation truncated to fit
> Content-Type:	text/plain; charset=UTF-8;
> 
> Ralf Baechle wrote:
> > On Wed, May 25, 2005 at 11:51:43AM +0300, Jerry wrote:
> > 
> > 
> >>drivers/sound/sounddrivers.o: In function `sound_insert_unit':
> >>sound_core.c:(.text+0x1ac): undefined reference to `strcpy'
> >>sound_core.c:(.text+0x1ac): relocation truncated to fit: R_MIPS_26 against `strcpy'
> >>make[1]: *** [vmlinux] Ошибка 1
> >>make[1]: Leaving directory `/work/video/kernel'
> >>make: *** [vmlinux] Ошибка 2
> >>
> >>It's not a "sound drivers" problem, howewer without it kernel compiles
> >>and run succesfully. Seems like gcc/bunitils bug/feature. What have to
> >>be done to eliminate this error?
> >>
> >>GNU ld version 2.15.96 20050308
> >>gcc version 3.4.3
> > 
> > 
> > Don't use gcc 3.4 to compile Linux 2.4.  It may work for some kernel
> > configurations but it will fail for others.
> > 
> >   Ralf
> 
> I would've thought this was fixed in 2.4.x now.  You might try using newer 
> sources.  The below patch fixes the issue:
> 
> http://dev.gentoo.org/~kumba/tmp/gcc-strcpy-fix.patch
> 
> 
> As the original patch I found stated about gcc-3.4.x:
> 
> From: Jan Hubicka <jh@suse.cz>
> 
> GCC now converts sprintf (a,"%s",b) to strcpy.  This lose on kernel as
> strcpy is not inlined and not present in library, so one gets linker
> failure.  It seems to make sense to apply this optimization by hand.

That fixes just the tip of the iceberg.  You want to rebuild with
-ffreestanding which 2.6 already does.  With that applied still some
2.4 kernel configurations will run into a bunch of other gcc 3.4-related
bug and not last loads of warnings.

  Ralf

From raghunathan.venkatesan@wipro.com Wed May 25 16:05:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 May 2005 16:05:55 +0100 (BST)
Received: from wip-ec-wd.wipro.com ([IPv6:::ffff:203.101.113.39]:55504 "EHLO
	wip-ec-wd.wipro.com") by linux-mips.org with ESMTP
	id <S8225551AbVEYPFh>; Wed, 25 May 2005 16:05:37 +0100
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id 2845420554
	for <linux-mips@linux-mips.org>; Wed, 25 May 2005 20:26:43 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id 0FC5D2053D
	for <linux-mips@linux-mips.org>; Wed, 25 May 2005 20:26:43 +0530 (IST)
Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 25 May 2005 20:35:27 +0530
Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 25 May 2005 20:35:24 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C5613B.2E4B5FBD"
Subject: RE: Unable to handle kernel paging request at virtual address 04000460
Date:	Wed, 25 May 2005 20:32:03 +0530
Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0CF6283@CHN-SNR-MBX01.wipro.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Unable to handle kernel paging request at virtual address 04000460
Thread-Index: AcVgd+bKyjXc1BZZTzOXOhBhBJ2c9wAwfS0w
From:	<raghunathan.venkatesan@wipro.com>
To:	<philippedeswert@scarlet.be>
Cc:	<linux-mips@linux-mips.org>
X-OriginalArrivalTime: 25 May 2005 15:05:24.0672 (UTC) FILETIME=[2DA59C00:01C5613B]
Return-Path: <raghunathan.venkatesan@wipro.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7975
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raghunathan.venkatesan@wipro.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5613B.2E4B5FBD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Philippe,
We were able to build the cross ksymoops utility and converted couple of
Oops capture to analyze the dump. All the crashes were pointing to
skbuff issues. When packets are received, the __kfree_skb function is
crashing at some point and when packets are transmitted the
skb_drop_fraglist is crashing at some point.

Please find attached the oops decoded dumps.=20
We would like to know are there any patches that need to be applied for
2.4.26 for it to handle fragmented packets when load is heavy ? We use
flood ping test on linux to get the crashes.

Thanks for your info.
Regards,
Raghu



-----Original Message-----
From: Philippe De Swert [mailto:philippedeswert@scarlet.be]=20
Sent: Tuesday, May 24, 2005 9:17 PM
To: Raghunathan Venkatesan (WT01 - EMBEDDED & PRODUCT ENGINEERING
SOLUTIONS)
Cc: linux-mips
Subject: Re:Unable to handle kernel paging request at virtual address
04000460

Decode this dump with ksymoops

See here:
http://freshmeat.net/projects/ksymoops/

This will help you discover in which function it is dying, on which
offset in your kernel code etc... Very helpful for debugging. (in 2.6
you can even compile something alike in the kernel (kallsyms))


---------- Initial header -----------

> We are facing the following crash in custom Linux 2.4.26 kernel, when=20
> we run a netperf TCP Stream (sizes varying from 64 to 32586 bytes)=20
> test over an IPSEC tunnel created between a host and a VPN server=20
> through our box. This is a Au1550 MIPS32 based board (DB1550 Cabernet=20
> board from AMD). We observe that crash happens randomly (the PrId=20
> keeps changing at each crash), because of burstiness in the netperf=20
> tool generated traffic. Please look into the following capture below.=20
> I'd like some help in debugging this issue. The same set of IPSEC=20
> drivers works fine on a custom Linux 2.4.25 based kernel. Is there a=20
> patch that needs to be applied for Linux 2.4.26 ?
> =20
> Unable to handle kernel paging request at virtual address 04000460,=20
> epc =3D=3D 802501cc, 8Oops in fault.c::do_page_fault, line 206:
>=20
> $0 : 00000000 1000fc00 00000000 00000001 00000000 8b5f61b2 04000460=20
> 00000000
<SNIP> KERNEL DUMP

CHEERS,

Philippe
=20
| Philippe De Swert      =20
|     =20
| Stag developer http://stag.mind.be/
| Emdebian developer: http://www.emdebian.org
|  =20
| Please do not send me documents in a closed=20
| format.(*.doc,*.xls,*.ppt)   =20
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)   =20
| http://www.gnu.org/philosophy/no-word-attachments.html

-------------------------------------------------------
NOTE! My email address is changing to ... @scarlet.be Please make the
necessary changes in your address book.=20




------_=_NextPart_001_01C5613B.2E4B5FBD
Content-Type: application/octet-stream;
	name="recent.cap_send1.oops"
Content-Transfer-Encoding: base64
Content-Description: recent.cap_send1.oops
Content-Disposition: attachment;
	filename="recent.cap_send1.oops"

a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK
ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg
ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v
IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1
bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh
dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu
IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg
dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDIwMDA0
ZDQsIGVwYyA9PSA4MDI0YWY2YywgcmEgPT0gODAyNGIwOTQKT29wcyBpbiBmYXVsdC5jOjpkb19w
YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAxMDAwZmMwMCA4YWJiYjYwMCAwMjAw
MDQ2MCAwMjAwMDQ2MCA4YWJiYjVlYyAwMDAwMDAwMCAwMDAwMDVlYwokOCA6IDVhZDM0MzZlIDhh
YmJiZGVjIGIzZGU1ZDcxIDU2NzM2OTg4IDA3ODNmZGZiIDgwMzIzODU4IDgwMzIzODA0IDI0ZTEy
YWU1CiQxNjogMDIwMDA0NjAgMDAwMDAwMDEgOGFiYmI4MDAgMDAwMDA2MDAgMDAwMDBjZmMgMDAw
MDA1ZGMgMDAwMDAwMTQgMDAwMDM0MDgKJDI0OiAwMDAwMDAwMCAyYWVhM2M3MCAgICAgICAgICAg
ICAgICAgICA4MDMyMjAwMCA4MDMyM2EyOCAwMDAwMzQxYyA4MDI0YjA5NApIaSA6IDAwMDAwMDAw
CkxvIDogMDAwMDA4MDAKZXBjICAgOiA4MDI0YWY2YyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw
MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAsIHN0YWNrcGFn
ZT04MDMyMjAwMCkKU3RhY2s6ICAgIDhiOTYyNDgwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw
IDAwMDAwODAwIDhiNmFmNDYwIDgwMjRiMDk0CiA4YjZhZjQ2MCA4YWJiYjgwMCAwMDAwMDYwMCAw
MDAwMGNmYyAwMDAwMDVkYyAwMDAwMDgwMCA4YjZhZjQ2MCA4MDI0YjdjYwogODAyNGI3YjAgMjRl
MTJhZTUgODAzMjM4NTggODAzMjM4MDQgYzAxYzIwNTAgOGI2YWY0NjAgODAzYTA0MDAgMDAwMDA1
YzgKIDgxMmJlMzAwIDgwMjUwMWQ0IDAwMDAwNWRjIDAwMDAwMDE0IDAwMDAyZTQwIDAwMDAwMDAw
IDJhZWEzYzcwIDhiNmFmNDYwCiA4YWVhMTE2MCAwMDAwMDVjOCA4MDI2YTllOCAwMDAwMmU1NCA4
MDI2YTE4NCAxMDAwZmMwMyAwMDAwMDAwMCA4YjZhZjQ2MAogOGFiYmIwMTAgLi4uCkNhbGwgVHJh
Y2U6ICAgWzw4MDI0YjA5ND5dIFs8ODAyNGI3Y2M+XSBbPDgwMjRiN2IwPl0gWzw4MDI1MDFkND5d
IFs8ODAyNmE5ZTg+XQogWzw4MDI2YTE4ND5dIFs8ODAyNmEzMGM+XSBbPDgwMjZhMWRjPl0gWzw4
MDI2YTkwYz5dIFs8ODAyNmE5MGM+XSBbPDgwMjljNDE4Pl0KIFs8ODAyNmE5MGM+XSBbPDgwMjZh
OTBjPl0gWzw4MDI1YTQ4ND5dIFs8ODAyNmE5MGM+XSBbPDgwMjZhOTBjPl0gWzw4MDI1YTk0OD5d
CiBbPDgwMmRhMGUwPl0gWzw4MDI2YTkwYz5dIFs8ODAyNmE4ZDQ+XSBbPDgwMjZhOTBjPl0gWzw4
MDI2YTMwYz5dIFs8ODAyNmExODQ+XQogWzw4MDI2NzEzMD5dIFs8ODAyNjcxYjA+XSBbPDgwMjZh
NzQ0Pl0gWzw4MDI1YTk4Yz5dIFs8ODAyOWVkODg+XSBbPDgwMjY3MTMwPl0KIFs8ODAyOWZkMzQ+
XSBbPDgwMjY3MDZjPl0gWzw4MDI2NzEzMD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1YTIwPl0gWzw4
MDI1YTQ4ND5dCiBbPGMwMWNlMmE4Pl0gWzw4MDI2NTdmOD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjVh
OThjPl0gWzw4MDI1YTk0OD5dIC4uLgpXYXJuaW5nIChPb3BzX3RyYWNlX2xpbmUpOiBnYXJiYWdl
ICcuLi4nIGF0IGVuZCBvZiB0cmFjZSBsaW5lIGlnbm9yZWQKQ29kZTogOGM1MDAwMDggIGFjNDAw
MDA4ICAwMjAwMjAyMSA8OGM4MjAwNzQ+IDEwNTEwMDA5ICA4ZTEwMDAwMCAgYzA4MzAwNzQgIDAw
NzExMDIzICBlMDgyMDA3NAoKCj4+UkE7ICAwMDAwMDAwMDgwMjRiMDk0IDxza2JfcmVsZWFzZV9k
YXRhK2IwL2JjPgo+PiQxMzsgMDAwMDAwMDA4MDMyMzg1OCA8aW5pdF90YXNrX3VuaW9uKzE4NTgv
MjAwMD4KPj4kMTQ7IDAwMDAwMDAwODAzMjM4MDQgPGluaXRfdGFza191bmlvbisxODA0LzIwMDA+
Cj4+JDI4OyAwMDAwMDAwMDgwMzIyMDAwIDxpbml0X3Rhc2tfdW5pb24rMC8yMDAwPgo+PiQyOTsg
MDAwMDAwMDA4MDMyM2EyOCA8aW5pdF90YXNrX3VuaW9uKzFhMjgvMjAwMD4KPj4kMzE7IDAwMDAw
MDAwODAyNGIwOTQgPHNrYl9yZWxlYXNlX2RhdGErYjAvYmM+Cgo+PlBDOyAgMDAwMDAwMDA4MDI0
YWY2YyA8c2tiX2Ryb3BfZnJhZ2xpc3QrMzQvNzQ+ICAgPD09PT09CgpUcmFjZTsgMDAwMDAwMDA4
MDI0YjA5NCA8c2tiX3JlbGVhc2VfZGF0YStiMC9iYz4KVHJhY2U7IDAwMDAwMDAwODAyNGI3Y2Mg
PHNrYl9saW5lYXJpemUrYzQvMTRjPgpUcmFjZTsgMDAwMDAwMDA4MDI0YjdiMCA8c2tiX2xpbmVh
cml6ZSthOC8xNGM+ClRyYWNlOyAwMDAwMDAwMDgwMjUwMWQ0IDxkZXZfcXVldWVfeG1pdCs1MC8z
Yjg+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9maW5pc2hfb3V0cHV0MitlYy8xNTA+ClRy
YWNlOyAwMDAwMDAwMDgwMjZhMTg0IDxpcF9mcmFnbWVudCsyNDAvNTAwPgpUcmFjZTsgMDAwMDAw
MDA4MDI2YTMwYyA8aXBfZnJhZ21lbnQrM2M4LzUwMD4KVHJhY2U7IDAwMDAwMDAwODAyNmExZGMg
PGlwX2ZyYWdtZW50KzI5OC81MDA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hf
b3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0
MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjljNDE4IDxpcF9yZWZyYWcrNjgvNzQ+ClRyYWNl
OyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAw
MDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgw
MjVhNDg0IDxuZl9pdGVyYXRlKzk0LzExND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2Zp
bmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2ZpbmlzaF9v
dXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgv
MWY4PgpUcmFjZTsgMDAwMDAwMDA4MDJkYTBlMCA8bWVtc2V0KzAvMWM+ClRyYWNlOyAwMDAwMDAw
MDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZh
OGQ0IDxpcF9maW5pc2hfb3V0cHV0KzFhMC8xYTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxp
cF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhMzBjIDxpcF9mcmFn
bWVudCszYzgvNTAwPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTE4NCA8aXBfZnJhZ21lbnQrMjQwLzUw
MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFj
ZTsgMDAwMDAwMDA4MDI2NzFiMCA8aXBfZm9yd2FyZF9maW5pc2grOTAvYTA+ClRyYWNlOyAwMDAw
MDAwMDgwMjZhNzQ0IDxpcF9maW5pc2hfb3V0cHV0KzEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAy
NWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI5ZWQ4OCA8aXBf
Y3RfcmVmcmVzaCs4NC9iOD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmlu
aXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAwMDA4MDI5ZmQzNCA8aWNtcF9wYWNrZXQrOTgvOWM+ClRy
YWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxfX2dudV9jb21waWxlZF9jKzI2Yy8zMjA+ClRyYWNlOyAw
MDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAw
ODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NWEyMCA8
aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0
ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMGMwMWNlMmE4IDxFTkRfT0ZfQ09ERSszZmUzYmFhOC8/
Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNl
OyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAwMDAw
ODAyNWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8
bmZfaG9va19zbG93KzEyOC8xZjg+CgpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2MCA8c2tiX2Ryb3Bf
ZnJhZ2xpc3QrMjgvNzQ+CjAwMDAwMDAwIDxfUEM+OgpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2MCA8
c2tiX2Ryb3BfZnJhZ2xpc3QrMjgvNzQ+CiAgIDA6ICAgOGM1MDAwMDggIGx3ICAgICAgczAsOCh2
MCkKQ29kZTsgIDAwMDAwMDAwODAyNGFmNjQgPHNrYl9kcm9wX2ZyYWdsaXN0KzJjLzc0PgogICA0
OiAgIGFjNDAwMDA4ICBzdyAgICAgIHplcm8sOCh2MCkKQ29kZTsgIDAwMDAwMDAwODAyNGFmNjgg
PHNrYl9kcm9wX2ZyYWdsaXN0KzMwLzc0PgogICA4OiAgIDAyMDAyMDIxICBtb3ZlICAgIGEwLHMw
CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjZjIDxza2JfZHJvcF9mcmFnbGlzdCszNC83ND4gICA8PT09
PT0KICAgYzogICA4YzgyMDA3NCAgbHcgICAgICB2MCwxMTYoYTApICAgPD09PT09CkNvZGU7ICAw
MDAwMDAwMDgwMjRhZjcwIDxza2JfZHJvcF9mcmFnbGlzdCszOC83ND4KICAxMDogICAxMDUxMDAw
OSAgYmVxICAgICB2MCxzMSwzOCA8X1BDKzB4Mzg+CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjc0IDxz
a2JfZHJvcF9mcmFnbGlzdCszYy83ND4KICAxNDogICA4ZTEwMDAwMCAgbHcgICAgICBzMCwwKHMw
KQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY3OCA8c2tiX2Ryb3BfZnJhZ2xpc3QrNDAvNzQ+CiAgMTg6
ICAgYzA4MzAwNzQgIGxsICAgICAgdjEsMTE2KGEwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY3YyA8
c2tiX2Ryb3BfZnJhZ2xpc3QrNDQvNzQ+CiAgMWM6ICAgMDA3MTEwMjMgIHN1YnUgICAgdjAsdjEs
czEKQ29kZTsgIDAwMDAwMDAwODAyNGFmODAgPHNrYl9kcm9wX2ZyYWdsaXN0KzQ4Lzc0PgogIDIw
OiAgIGUwODIwMDc0ICBzYyAgICAgIHYwLDExNihhMCkKCktlcm5lbCBwYW5pYzogQWllZSwga2ls
bGluZyBpbnRlcnJ1cHQgaGFuZGxlciEKCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBu
b3QgYmUgcmVsaWFibGUuCg==

------_=_NextPart_001_01C5613B.2E4B5FBD
Content-Type: application/octet-stream;
	name="recent.cap.oops"
Content-Transfer-Encoding: base64
Content-Description: recent.cap.oops
Content-Disposition: attachment;
	filename="recent.cap.oops"

a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK
ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg
ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v
IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1
bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh
dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu
IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg
dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDQwMDA0
NjAsIGVwYyA9PSA4MDI0YjIwYywgcmEgPT0gODAyYzQ5ZjgKT29wcyBpbiBmYXVsdC5jOjpkb19w
YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw
MDAwMSA4Yjc4MzU4MCAwMDAwMDAwMCAwNDAwMDQ2MCAwMDAwMDAwMQokOCA6IDAwMDAwMDAwIDAw
MDAwMDAwIDAwMDAwMDAyIGQzZDBiMDAwIDgwMzIzYjY4IDAwMDAwMDAwIDgwMzIzZDYwIDdiN2E3
OTc4CiQxNjogODEyYmViMjAgODEyYmViMjAgZmZmZmZmZmYgOGJiMGQ4MDAgODAzYTA4MDQgMDAw
MDAwMDAgMDAwMDAwMDIgODAzMjNlMTAKJDI0OiAwMDAwMDAwMCAyYjAwYWM3MCAgICAgICAgICAg
ICAgICAgICA4MDMyMjAwMCA4MDMyM2FkMCAwMDAwMjQwMSA4MDJjNDlmOApIaSA6IDAwMDAyMDkx
CkxvIDogZDY5MTI4NWUKZXBjICAgOiA4MDI0YjIwYyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw
MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAsIHN0YWNrcGFn
ZT04MDMyMjAwMCkKU3RhY2s6ICAgIDAwMDAwMDAwIDhiYjBkODAwIDgwM2EwODA0IDAwMDAwMDAw
IDgxMmJlYjIwIDgwMmM0OWY4IDgwMTA3YzI4CiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCA4
MTJiZWIyMCA4MTI0ZmM2OCA4YjZhZjVhMCA4MDNhMDgwMCAwMDAwMDAwNAogODAyNTAwODggMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgODEyYjY1NjAgODAzYTA4MDAgOGI2YWY1
YTAKIDgwM2EwODAwIDAwMDAwMDAwIDgwMjVjM2UwIDAwMDAwMDAwIDAwMDAwMDAwIDgwMzIzYzE4
IDgwMzY5YmYwIDgwMzRkN2U4CiA4MDNhMDgwMCAwMDAwMDAwMCA4MDI1MDM3YyA4MDI5YzNlYyAw
MDAwMDAwMCA4Yjc4MzU4MCA4YjZhZjVhMCAwMDAwMDAwZQogOGI2YWY1YTAgLi4uCkNhbGwgVHJh
Y2U6ICAgWzw4MDJjNDlmOD5dIFs8ODAxMDdjMjg+XSBbPDgwMjUwMDg4Pl0gWzw4MDI1YzNlMD5d
IFs8ODAyNTAzN2M+XQogWzw4MDI5YzNlYz5dIFs8ODAyNTczYTg+XSBbPDgwMjVhNDg0Pl0gWzw4
MDI2YTkwYz5dIFs8ODAyNmE5ZTg+XSBbPDgwMjZhOTBjPl0KIFs8ODAyNWE5OGM+XSBbPDgwMjVh
OTQ4Pl0gWzw4MDI2YTkwYz5dIFs8ODAyYTNkOTg+XSBbPDgwMjY3MTMwPl0gWzw4MDI2YThkND5d
CiBbPDgwMjZhOTBjPl0gWzw4MDI2NzFjMD5dIFs8ODAyNjcxMzA+XSBbPDgwMjVhOThjPl0gWzw4
MDI5Y2Y1MD5dIFs8ODAyNjcxMzA+XQogWzw4MDI5ZmQwND5dIFs8ODAyNjcwNmM+XSBbPDgwMjY3
MTMwPl0gWzw4MDI2NTdmOD5dIFs8ODAyNjVhMjA+XSBbPDgwMjVhNDg0Pl0KIFs8YzAxY2UyYTg+
XSBbPDgwMjY1N2Y4Pl0gWzw4MDI2NTdmOD5dIFs8ODAyNWE5OGM+XSBbPDgwMjVhOTQ4Pl0gWzw4
MDI2NTdmOD5dCiBbPDgwMjY1NWEwPl0gWzw4MDI2NTdmOD5dIFs8ODAyNTBkNDg+XSBbPDgwMmUw
MWY0Pl0gWzw4MDEwN2MyOD5dIC4uLgpXYXJuaW5nIChPb3BzX3RyYWNlX2xpbmUpOiBnYXJiYWdl
ICcuLi4nIGF0IGVuZCBvZiB0cmFjZSBsaW5lIGlnbm9yZWQKQ29kZTogOGUwNjAwOWMgIDEwYzAw
MDBlICAyNDAzMDAwMSA8OGNjMjAwMDA+IGMwNDUwMDAwICAwMGEzMjAyMyAgZTA0NDAwMDAgIDEw
ODBmZmZjICAwMGEzMjAyMwoKCj4+UkE7ICAwMDAwMDAwMDgwMmM0OWY4IDxwYWNrZXRfcmN2X3Nw
a3QrMjljLzJiMD4KPj4kMTI7IDAwMDAwMDAwODAzMjNiNjggPGluaXRfdGFza191bmlvbisxYjY4
LzIwMDA+Cj4+JDE0OyAwMDAwMDAwMDgwMzIzZDYwIDxpbml0X3Rhc2tfdW5pb24rMWQ2MC8yMDAw
Pgo+PiQyMzsgMDAwMDAwMDA4MDMyM2UxMCA8aW5pdF90YXNrX3VuaW9uKzFlMTAvMjAwMD4KPj4k
Mjg7IDAwMDAwMDAwODAzMjIwMDAgPGluaXRfdGFza191bmlvbiswLzIwMDA+Cj4+JDI5OyAwMDAw
MDAwMDgwMzIzYWQwIDxpbml0X3Rhc2tfdW5pb24rMWFkMC8yMDAwPgo+PiQzMTsgMDAwMDAwMDA4
MDJjNDlmOCA8cGFja2V0X3Jjdl9zcGt0KzI5Yy8yYjA+Cgo+PlBDOyAgMDAwMDAwMDA4MDI0YjIw
YyA8X19rZnJlZV9za2IrYTQvMTMwPiAgIDw9PT09PQoKVHJhY2U7IDAwMDAwMDAwODAyYzQ5Zjgg
PHBhY2tldF9yY3Zfc3BrdCsyOWMvMmIwPgpUcmFjZTsgMDAwMDAwMDA4MDEwN2MyOCA8ZG9fZ2V0
dGltZW9mZGF5KzU4LzExND4KVHJhY2U7IDAwMDAwMDAwODAyNTAwODggPGRldl9xdWV1ZV94bWl0
X25pdCtiYy8xMTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVjM2UwIDxfX2dudV9jb21waWxlZF9jKzcw
LzE0Yz4KVHJhY2U7IDAwMDAwMDAwODAyNTAzN2MgPGRldl9xdWV1ZV94bWl0KzFmOC8zYjg+ClRy
YWNlOyAwMDAwMDAwMDgwMjljM2VjIDxpcF9yZWZyYWcrM2MvNzQ+ClRyYWNlOyAwMDAwMDAwMDgw
MjU3M2E4IDxuZWlnaF9yZXNvbHZlX291dHB1dCsxZmMvMjljPgpUcmFjZTsgMDAwMDAwMDA4MDI1
YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5p
c2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9maW5pc2hfb3V0
cHV0MitlYy8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0Misx
MC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJh
Y2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFjZTsgMDAwMDAw
MDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDJh
M2Q5OCA8aXB0X2xvY2FsX291dF9ob29rKzQvOGM+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxp
cF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNmE4ZDQgPGlwX2Zpbmlz
aF9vdXRwdXQrMWEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2ZpbmlzaF9vdXRw
dXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxYzAgPGlwX29wdGlvbnNfYnVpbGQrMC8w
PgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAvYTA+ClRyYWNl
OyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7IDAwMDAwMDAw
ODAyOWNmNTAgPGRlYXRoX2J5X3RpbWVvdXQrM2MvYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMw
IDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyOWZkMDQgPGljbXBf
cGFja2V0KzY4LzljPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzA2YyA8X19nbnVfY29tcGlsZWRfYysy
NmMvMzIwPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAvYTA+
ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAw
MDAwMDAwODAyNjVhMjAgPGlwX3Jjdl9maW5pc2grMjM4LzJhOD4KVHJhY2U7IDAwMDAwMDAwODAy
NWE0ODQgPG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDBjMDFjZTJhOCA8RU5EX09G
X0NPREUrM2ZlM2JhYTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5p
c2grMTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+
ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7IDAw
MDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI2
NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1NWEwIDxpcF9y
Y3YrNTEwLzU3OD4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4
PgpUcmFjZTsgMDAwMDAwMDA4MDI1MGQ0OCA8bmV0aWZfcmVjZWl2ZV9za2IrMjcwLzJjMD4KVHJh
Y2U7IDAwMDAwMDAwODAyZTAxZjQgPGF1MTAwMF9JUlErMTM0LzFhMD4KVHJhY2U7IDAwMDAwMDAw
ODAxMDdjMjggPGRvX2dldHRpbWVvZmRheSs1OC8xMTQ+CgpDb2RlOyAgMDAwMDAwMDA4MDI0YjIw
MCA8X19rZnJlZV9za2IrOTgvMTMwPgowMDAwMDAwMCA8X1BDPjoKQ29kZTsgIDAwMDAwMDAwODAy
NGIyMDAgPF9fa2ZyZWVfc2tiKzk4LzEzMD4KICAgMDogICA4ZTA2MDA5YyAgbHcgICAgICBhMiwx
NTYoczApCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjA0IDxfX2tmcmVlX3NrYis5Yy8xMzA+CiAgIDQ6
ICAgMTBjMDAwMGUgIGJlcXogICAgYTIsNDAgPF9QQysweDQwPgpDb2RlOyAgMDAwMDAwMDA4MDI0
YjIwOCA8X19rZnJlZV9za2IrYTAvMTMwPgogICA4OiAgIDI0MDMwMDAxICBsaSAgICAgIHYxLDEK
Q29kZTsgIDAwMDAwMDAwODAyNGIyMGMgPF9fa2ZyZWVfc2tiK2E0LzEzMD4gICA8PT09PT0KICAg
YzogICA4Y2MyMDAwMCAgbHcgICAgICB2MCwwKGEyKSAgIDw9PT09PQpDb2RlOyAgMDAwMDAwMDA4
MDI0YjIxMCA8X19rZnJlZV9za2IrYTgvMTMwPgogIDEwOiAgIGMwNDUwMDAwICBsbCAgICAgIGEx
LDAodjApCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjE0IDxfX2tmcmVlX3NrYithYy8xMzA+CiAgMTQ6
ICAgMDBhMzIwMjMgIHN1YnUgICAgYTAsYTEsdjEKQ29kZTsgIDAwMDAwMDAwODAyNGIyMTggPF9f
a2ZyZWVfc2tiK2IwLzEzMD4KICAxODogICBlMDQ0MDAwMCAgc2MgICAgICBhMCwwKHYwKQpDb2Rl
OyAgMDAwMDAwMDA4MDI0YjIxYyA8X19rZnJlZV9za2IrYjQvMTMwPgogIDFjOiAgIDEwODBmZmZj
ICBiZXF6ICAgIGEwLDEwIDxfUEMrMHgxMD4KQ29kZTsgIDAwMDAwMDAwODAyNGIyMjAgPF9fa2Zy
ZWVfc2tiK2I4LzEzMD4KICAyMDogICAwMGEzMjAyMyAgc3VidSAgICBhMCxhMSx2MQoKS2VybmVs
IHBhbmljOiBBaWVlLCBraWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQoKMSB3YXJuaW5nIGlzc3Vl
ZC4gIFJlc3VsdHMgbWF5IG5vdCBiZSByZWxpYWJsZS4K

------_=_NextPart_001_01C5613B.2E4B5FBD
Content-Type: application/octet-stream;
	name="recent.cap_recv.oops"
Content-Transfer-Encoding: base64
Content-Description: recent.cap_recv.oops
Content-Disposition: attachment;
	filename="recent.cap_recv.oops"

a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK
ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg
ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v
IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1
bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh
dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu
IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg
dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDMy
NjAsIGVwYyA9PSA4MDI0YjIwYywgcmEgPT0gODAyYzQ5ZjgKT29wcyBpbiBmYXVsdC5jOjpkb19w
YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw
MDAwMSA4Yjc4MDc2MCAwMDAwMDAwMCAwMDAwMzI2MCAwMDAwMDAwMQokOCA6IDAwMDAwMDAwIDAw
MDAwMDAwIDAwMDAwMDAyIGQzZDBiMDAwIGMwMTE1MDAwIDAwMDAxNGI4IDhiOWJmZDI4IDdiN2E3
OTc4CiQxNjogOGI2YjU0NjAgOGI2YjU0NjAgZmZmZmZmZmYgOGI5MGY4MDAgODAzYTA4MDQgMDAw
MDAwMDAgMDAwMDAwMDIgOGI5YmZkZDgKJDI0OiAwMDAwMDAwMCAyYWNhZDU1MCAgICAgICAgICAg
ICAgICAgICA4YjliZTAwMCA4YjliZmE5OCAwMDAwNDc5ZCA4MDJjNDlmOApIaSA6IDAwMDAyMzYx
CkxvIDogNzY1MGYxMDgKZXBjICAgOiA4MDI0YjIwYyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw
MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyB2b3Nsb2cgKHBpZDogMTM0LCBzdGFja3Bh
Z2U9OGI5YmUwMDApClN0YWNrOiAgICAwMDAwMDAwMCA4YjkwZjgwMCA4MDNhMDgwNCAwMDAwMDAw
MCA4YjZiNTQ2MCA4MDJjNDlmOCA4MDEwN2MyOAogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAg
OGI2YjU0NjAgODEyNGZjNjggODEyYmVkMDAgODAzYTA4MDAgMDAwMDAwMDQKIDgwMjUwMDg4IDAw
MDAwMDAwIDAwMDAwMDAwIDgwMjlkMzgwIDAwMDAwMDAwIDgxMmI2NTYwIDgwM2EwODAwIDgxMmJl
ZDAwCiA4MDNhMDgwMCAwMDAwMDAwMCA4MDI1YzNlMCA4MDI2YTkwYyAwMDAwMDAwMyAwMDAwMDAw
MiA4MDI5YzNhYyA4MDM0ZDdlOAogODAzYTA4MDAgMDAwMDAwMDAgODAyNTAzN2MgODAyOWMzZWMg
MDAwMDAwMDAgOGI3ODA3NjAgODEyYmVkMDAgMDAwMDAwMGUKIDgxMmJlZDAwIC4uLgpDYWxsIFRy
YWNlOiAgIFs8ODAyYzQ5Zjg+XSBbPDgwMTA3YzI4Pl0gWzw4MDI1MDA4OD5dIFs8ODAyOWQzODA+
XSBbPDgwMjVjM2UwPl0KIFs8ODAyNmE5MGM+XSBbPDgwMjljM2FjPl0gWzw4MDI1MDM3Yz5dIFs8
ODAyOWMzZWM+XSBbPDgwMjU3M2E4Pl0gWzw4MDI1YTQ4ND5dCiBbPDgwMjZhOTBjPl0gWzw4MDI2
YTllOD5dIFs8ODAyNmE5MGM+XSBbPDgwMjVhOThjPl0gWzw4MDI1YTk0OD5dIFs8ODAyNmE5MGM+
XQogWzw4MDJhM2Q5OD5dIFs8ODAyNjcxMzA+XSBbPDgwMjZhOGQ0Pl0gWzw4MDI2YTkwYz5dIFs8
ODAyNjcxYzA+XSBbPDgwMjY3MTMwPl0KIFs8ODAyNWE5OGM+XSBbPDgwMjY3MTMwPl0gWzw4MDI5
ZmQzND5dIFs8ODAyNjcwNmM+XSBbPDgwMjY3MTMwPl0gWzw4MDI2NTdmOD5dCiBbPDgwMjY1YTIw
Pl0gWzw4MDI1YTQ4ND5dIFs8YzAxY2UyYTg+XSBbPDgwMjY1N2Y4Pl0gWzw4MDI2NTdmOD5dIFs8
ODAyNWE5OGM+XQogWzw4MDI1YTk0OD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1NWEwPl0gWzw4MDI2
NTdmOD5dIFs8ODAxMDEzM2M+XSAuLi4KV2FybmluZyAoT29wc190cmFjZV9saW5lKTogZ2FyYmFn
ZSAnLi4uJyBhdCBlbmQgb2YgdHJhY2UgbGluZSBpZ25vcmVkCkNvZGU6IDhlMDYwMDljICAxMGMw
MDAwZSAgMjQwMzAwMDEgPDhjYzIwMDAwPiBjMDQ1MDAwMCAgMDBhMzIwMjMgIGUwNDQwMDAwICAx
MDgwZmZmYyAgMDBhMzIwMjMKCgo+PlJBOyAgMDAwMDAwMDA4MDJjNDlmOCA8cGFja2V0X3Jjdl9z
cGt0KzI5Yy8yYjA+Cj4+JDMxOyAwMDAwMDAwMDgwMmM0OWY4IDxwYWNrZXRfcmN2X3Nwa3QrMjlj
LzJiMD4KCj4+UEM7ICAwMDAwMDAwMDgwMjRiMjBjIDxfX2tmcmVlX3NrYithNC8xMzA+ICAgPD09
PT09CgpUcmFjZTsgMDAwMDAwMDA4MDJjNDlmOCA8cGFja2V0X3Jjdl9zcGt0KzI5Yy8yYjA+ClRy
YWNlOyAwMDAwMDAwMDgwMTA3YzI4IDxkb19nZXR0aW1lb2ZkYXkrNTgvMTE0PgpUcmFjZTsgMDAw
MDAwMDA4MDI1MDA4OCA8ZGV2X3F1ZXVlX3htaXRfbml0K2JjLzExMD4KVHJhY2U7IDAwMDAwMDAw
ODAyOWQzODAgPF9faXBfY29ubnRyYWNrX2NvbmZpcm0rMjM4LzJjOD4KVHJhY2U7IDAwMDAwMDAw
ODAyNWMzZTAgPF9fZ251X2NvbXBpbGVkX2MrNzAvMTRjPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkw
YyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI5YzNhYyA8aXBf
Y29uZmlybSs0OC80Yz4KVHJhY2U7IDAwMDAwMDAwODAyNTAzN2MgPGRldl9xdWV1ZV94bWl0KzFm
OC8zYjg+ClRyYWNlOyAwMDAwMDAwMDgwMjljM2VjIDxpcF9yZWZyYWcrM2MvNzQ+ClRyYWNlOyAw
MDAwMDAwMDgwMjU3M2E4IDxuZWlnaF9yZXNvbHZlX291dHB1dCsxZmMvMjljPgpUcmFjZTsgMDAw
MDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBj
IDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9m
aW5pc2hfb3V0cHV0MitlYy8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hf
b3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZj
LzFmOD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFj
ZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAw
MDAwMDA4MDJhM2Q5OCA8aXB0X2xvY2FsX291dF9ob29rKzQvOGM+ClRyYWNlOyAwMDAwMDAwMDgw
MjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNmE4ZDQg
PGlwX2ZpbmlzaF9vdXRwdXQrMWEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2Zp
bmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxYzAgPGlwX29wdGlvbnNf
YnVpbGQrMC8wPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAv
YTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7
IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAw
MDA4MDI5ZmQzNCA8aWNtcF9wYWNrZXQrOTgvOWM+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxf
X2dudV9jb21waWxlZF9jKzI2Yy8zMjA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3
YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2gr
MTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NWEyMCA8aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpU
cmFjZTsgMDAwMDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAw
MGMwMWNlMmE4IDxFTkRfT0ZfQ09ERSszZmUzYmFhOC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2
NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9y
Y3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hvb2tfc2xvdysx
NmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRy
YWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAw
MDAwODAyNjU1YTAgPGlwX3Jjdis1MTAvNTc4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBf
cmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMTAxMzNjIDxkb19JUlErZjQvMTE4
PgoKQ29kZTsgIDAwMDAwMDAwODAyNGIyMDAgPF9fa2ZyZWVfc2tiKzk4LzEzMD4KMDAwMDAwMDAg
PF9QQz46CkNvZGU7ICAwMDAwMDAwMDgwMjRiMjAwIDxfX2tmcmVlX3NrYis5OC8xMzA+CiAgIDA6
ICAgOGUwNjAwOWMgIGx3ICAgICAgYTIsMTU2KHMwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YjIwNCA8
X19rZnJlZV9za2IrOWMvMTMwPgogICA0OiAgIDEwYzAwMDBlICBiZXF6ICAgIGEyLDQwIDxfUEMr
MHg0MD4KQ29kZTsgIDAwMDAwMDAwODAyNGIyMDggPF9fa2ZyZWVfc2tiK2EwLzEzMD4KICAgODog
ICAyNDAzMDAwMSAgbGkgICAgICB2MSwxCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjBjIDxfX2tmcmVl
X3NrYithNC8xMzA+ICAgPD09PT09CiAgIGM6ICAgOGNjMjAwMDAgIGx3ICAgICAgdjAsMChhMikg
ICA8PT09PT0KQ29kZTsgIDAwMDAwMDAwODAyNGIyMTAgPF9fa2ZyZWVfc2tiK2E4LzEzMD4KICAx
MDogICBjMDQ1MDAwMCAgbGwgICAgICBhMSwwKHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YjIxNCA8
X19rZnJlZV9za2IrYWMvMTMwPgogIDE0OiAgIDAwYTMyMDIzICBzdWJ1ICAgIGEwLGExLHYxCkNv
ZGU7ICAwMDAwMDAwMDgwMjRiMjE4IDxfX2tmcmVlX3NrYitiMC8xMzA+CiAgMTg6ICAgZTA0NDAw
MDAgIHNjICAgICAgYTAsMCh2MCkKQ29kZTsgIDAwMDAwMDAwODAyNGIyMWMgPF9fa2ZyZWVfc2ti
K2I0LzEzMD4KICAxYzogICAxMDgwZmZmYyAgYmVxeiAgICBhMCwxMCA8X1BDKzB4MTA+CkNvZGU7
ICAwMDAwMDAwMDgwMjRiMjIwIDxfX2tmcmVlX3NrYitiOC8xMzA+CiAgMjA6ICAgMDBhMzIwMjMg
IHN1YnUgICAgYTAsYTEsdjEKCktlcm5lbCBwYW5pYzogQWllZSwga2lsbGluZyBpbnRlcnJ1cHQg
aGFuZGxlciEKCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3QgYmUgcmVsaWFibGUu
Cg==

------_=_NextPart_001_01C5613B.2E4B5FBD
Content-Type: application/octet-stream;
	name="recent.cap_send.oops"
Content-Transfer-Encoding: base64
Content-Description: recent.cap_send.oops
Content-Disposition: attachment;
	filename="recent.cap_send.oops"

a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK
ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg
ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v
IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1
bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh
dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu
IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg
dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDMy
ZDQsIGVwYyA9PSA4MDI0YWY2YywgcmEgPT0gODAyNGIwOTQKT29wcyBpbiBmYXVsdC5jOjpkb19w
YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAxMDAwZmMwMCA4YWM4MWUwMCAwMDAw
MzI2MCAwMDAwMzI2MCAwMDAwMDAwMCAwMDAwMDAwMCA4YjM4YjM0MAokOCA6IDAwMDAwMDMwIDgw
MmRhMWEwIDAwMDAwMDEwIGJmYmViZGJjIGEzYTJhMWEwIDAwMDAwMDAwIDhhYjc5ZGU4IGE3YTZh
NWE0CiQxNjogMDAwMDMyNjAgMDAwMDAwMDEgOGFlYTgyNjAgYzAxNzI5NGMgMDAwMDAwMGYgODAy
NGIxNzggYzAxNjdhYjggYzAxNzI5NTAKJDI0OiAwMDAwMDAxMCAwMDQwZTBmMCAgICAgICAgICAg
ICAgICAgICA4YWI3ODAwMCA4YWI3OWE2OCBjMDE3MjdkOCA4MDI0YjA5NApIaSA6IDAwMDAwMDAw
CkxvIDogMDAwMDAwMGIKZXBjICAgOiA4MDI0YWY2YyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw
MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBtZG0td2lwcm8tbm8tZGUgKHBpZDogNDEw
LCBzdGFja3BhZ2U9OGFiNzgwMDApClN0YWNrOiAgICA4YWI3OWFkOCA4MDM2OWJmMCAwMDAwMDAw
NCA4MDI1YTQ4NCA4YjZiNTQ2MCA4YjZiNTQ2MCA4MDI0YjA5NAogZmZmYmM0NzMgODAyNmE5MGMg
ODAzYTA0MDAgODEyYmVhODAgODAzYTA0MDAgOGI2YjU0NjAgOGIzOGIzNjAgODAyNGIwYzQKIDAw
MDAwMDAwIDAwMDAwMDAyIDAwMDA0MGQyIDgwMmRhMGUwIDhhYjc5YzU4IDhiNmI1NDYwIDgwMjRi
Mjk4IDgxMmI2NDYwCiA4MDNhMDQwMCA4MDNhMDQwMCA4YWI3OWFkOCA4YjZiNTQ2MCBjMDE3MWY1
OCA4MTJiZWJjMCA4MDM5MDZhOCAwMDAwMDAyMAogODAyNGFlMzggOGI2YjU3ODAgOGFhYzQwZjYg
OGI0MjhkNjAgMDAwMDAwMDAgODEyYmViYzAgOGFhYzAwMTAgOGFlYTgyNjAKIDAwMDA0MGQyIC4u
LgpDYWxsIFRyYWNlOiAgIFs8ODAyNWE0ODQ+XSBbPDgwMjRiMDk0Pl0gWzw4MDI2YTkwYz5dIFs8
ODAyNGIwYzQ+XSBbPDgwMmRhMGUwPl0KIFs8ODAyNGIyOTg+XSBbPGMwMTcxZjU4Pl0gWzw4MDI0
YWUzOD5dIFs8ODAyZDlkODA+XSBbPGMwMTcxZTEwPl0gWzw4MDI2YTkwYz5dCiBbPGMwMTcyNDE0
Pl0gWzxjMDE3NDBlOD5dIFs8ODAyNWE0ODQ+XSBbPDgwMjZhOTBjPl0gWzw4MDI2YTkwYz5dIFs8
ODAyNWE5NDg+XQogWzw4MDJkYTBlMD5dIFs8ODAyNmE5MGM+XSBbPGMwMTc1MWRjPl0gWzw4MDI2
YThkND5dIFs8ODAyNmE5MGM+XSBbPDgwMjZhMzBjPl0KIFs8ODAyNmExODQ+XSBbPDgwMjY3MTMw
Pl0gWzw4MDI2NzFiMD5dIFs8ODAyNmE3NDQ+XSBbPDgwMjVhOThjPl0gWzw4MDI2NzEzMD5dCiBb
PDgwMjY3MDZjPl0gWzw4MDI2NzEzMD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1YTIwPl0gWzw4MDI1
YTQ4ND5dIFs8YzAxY2UyYTg+XQogWzw4MDI2NTdmOD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjVhOThj
Pl0gWzw4MDI1YTk0OD5dIFs8ODAyNjU3Zjg+XSAuLi4KV2FybmluZyAoT29wc190cmFjZV9saW5l
KTogZ2FyYmFnZSAnLi4uJyBhdCBlbmQgb2YgdHJhY2UgbGluZSBpZ25vcmVkCkNvZGU6IDhjNTAw
MDA4ICBhYzQwMDAwOCAgMDIwMDIwMjEgPDhjODIwMDc0PiAxMDUxMDAwOSAgOGUxMDAwMDAgIGMw
ODMwMDc0ICAwMDcxMTAyMyAgZTA4MjAwNzQKCgo+PlJBOyAgMDAwMDAwMDA4MDI0YjA5NCA8c2ti
X3JlbGVhc2VfZGF0YStiMC9iYz4KPj4kOTsgMDAwMDAwMDA4MDJkYTFhMCA8bWVtc2V0X3BhcnRp
YWwrMjQvNmM+Cj4+JDIxOyAwMDAwMDAwMDgwMjRiMTc4IDxfX2tmcmVlX3NrYisxMC8xMzA+Cj4+
JDMxOyAwMDAwMDAwMDgwMjRiMDk0IDxza2JfcmVsZWFzZV9kYXRhK2IwL2JjPgoKPj5QQzsgIDAw
MDAwMDAwODAyNGFmNmMgPHNrYl9kcm9wX2ZyYWdsaXN0KzM0Lzc0PiAgIDw9PT09PQoKVHJhY2U7
IDAwMDAwMDAwODAyNWE0ODQgPG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDA4MDI0
YjA5NCA8c2tiX3JlbGVhc2VfZGF0YStiMC9iYz4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlw
X2ZpbmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNGIwYzQgPGtmcmVlX3Nr
Ym1lbSsyNC9jOD4KVHJhY2U7IDAwMDAwMDAwODAyZGEwZTAgPG1lbXNldCswLzFjPgpUcmFjZTsg
MDAwMDAwMDA4MDI0YjI5OCA8c2tiX2Nsb25lKzAvMjUwPgpUcmFjZTsgMDAwMDAwMDBjMDE3MWY1
OCA8RU5EX09GX0NPREUrM2ZkZGY3NTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNGFlMzggPGFs
bG9jX3NrYisxNjAvMjYwPgpUcmFjZTsgMDAwMDAwMDA4MDJkOWQ4MCA8bWVtY3B5KzAvND4KVHJh
Y2U7IDAwMDAwMDAwYzAxNzFlMTAgPEVORF9PRl9DT0RFKzNmZGRmNjEwLz8/Pz8+ClRyYWNlOyAw
MDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAw
MGMwMTcyNDE0IDxFTkRfT0ZfQ09ERSszZmRkZmMxNC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDBjMDE3
NDBlOCA8RU5EX09GX0NPREUrM2ZkZTE4ZTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNWE0ODQg
PG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291
dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIr
MTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRy
YWNlOyAwMDAwMDAwMDgwMmRhMGUwIDxtZW1zZXQrMC8xYz4KVHJhY2U7IDAwMDAwMDAwODAyNmE5
MGMgPGlwX2ZpbmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwYzAxNzUxZGMgPEVO
RF9PRl9DT0RFKzNmZGUyOWRjLz8/Pz8+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOGQ0IDxpcF9maW5p
c2hfb3V0cHV0KzFhMC8xYTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0
cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhMzBjIDxpcF9mcmFnbWVudCszYzgvNTAw
PgpUcmFjZTsgMDAwMDAwMDA4MDI2YTE4NCA8aXBfZnJhZ21lbnQrMjQwLzUwMD4KVHJhY2U7IDAw
MDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAwMDA4
MDI2NzFiMCA8aXBfZm9yd2FyZF9maW5pc2grOTAvYTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhNzQ0
IDxpcF9maW5pc2hfb3V0cHV0KzEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hv
b2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5p
c2grMTAvYTA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxfX2dudV9jb21waWxlZF9jKzI2Yy8z
MjA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJh
Y2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4PgpUcmFjZTsgMDAwMDAw
MDA4MDI2NWEyMCA8aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTQ4
NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMGMwMWNlMmE4IDxFTkRfT0ZfQ09E
RSszZmUzYmFhOC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsx
MC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJh
Y2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAw
MDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4
IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjYwIDxza2JfZHJv
cF9mcmFnbGlzdCsyOC83ND4KMDAwMDAwMDAgPF9QQz46CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjYw
IDxza2JfZHJvcF9mcmFnbGlzdCsyOC83ND4KICAgMDogICA4YzUwMDAwOCAgbHcgICAgICBzMCw4
KHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2NCA8c2tiX2Ryb3BfZnJhZ2xpc3QrMmMvNzQ+CiAg
IDQ6ICAgYWM0MDAwMDggIHN3ICAgICAgemVybyw4KHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2
OCA8c2tiX2Ryb3BfZnJhZ2xpc3QrMzAvNzQ+CiAgIDg6ICAgMDIwMDIwMjEgIG1vdmUgICAgYTAs
czAKQ29kZTsgIDAwMDAwMDAwODAyNGFmNmMgPHNrYl9kcm9wX2ZyYWdsaXN0KzM0Lzc0PiAgIDw9
PT09PQogICBjOiAgIDhjODIwMDc0ICBsdyAgICAgIHYwLDExNihhMCkgICA8PT09PT0KQ29kZTsg
IDAwMDAwMDAwODAyNGFmNzAgPHNrYl9kcm9wX2ZyYWdsaXN0KzM4Lzc0PgogIDEwOiAgIDEwNTEw
MDA5ICBiZXEgICAgIHYwLHMxLDM4IDxfUEMrMHgzOD4KQ29kZTsgIDAwMDAwMDAwODAyNGFmNzQg
PHNrYl9kcm9wX2ZyYWdsaXN0KzNjLzc0PgogIDE0OiAgIDhlMTAwMDAwICBsdyAgICAgIHMwLDAo
czApCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjc4IDxza2JfZHJvcF9mcmFnbGlzdCs0MC83ND4KICAx
ODogICBjMDgzMDA3NCAgbGwgICAgICB2MSwxMTYoYTApCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjdj
IDxza2JfZHJvcF9mcmFnbGlzdCs0NC83ND4KICAxYzogICAwMDcxMTAyMyAgc3VidSAgICB2MCx2
MSxzMQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY4MCA8c2tiX2Ryb3BfZnJhZ2xpc3QrNDgvNzQ+CiAg
MjA6ICAgZTA4MjAwNzQgIHNjICAgICAgdjAsMTE2KGEwKQoKS2VybmVsIHBhbmljOiBBaWVlLCBr
aWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQoKMSB3YXJuaW5nIGlzc3VlZC4gIFJlc3VsdHMgbWF5
IG5vdCBiZSByZWxpYWJsZS4K

------_=_NextPart_001_01C5613B.2E4B5FBD--

From mile.davidovic@micronasnit.com Wed May 25 16:59:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 May 2005 16:59:29 +0100 (BST)
Received: from krt.tmd.ns.ac.yu ([IPv6:::ffff:147.91.177.65]:6352 "EHLO
	krt.neobee.net") by linux-mips.org with ESMTP id <S8225562AbVEYP7O>;
	Wed, 25 May 2005 16:59:14 +0100
Received: from localhost (localhost [127.0.0.1])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4PH8LjX017215
	for <linux-mips@linux-mips.org>; Wed, 25 May 2005 19:08:21 +0200
Received: from krt.neobee.net ([127.0.0.1])
 by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 17100-02 for <linux-mips@linux-mips.org>;
 Wed, 25 May 2005 19:08:21 +0200 (CEST)
Received: from davidovic ([192.168.0.89])
	by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j4PH8Jb4017205
	for <linux-mips@linux-mips.org>; Wed, 25 May 2005 19:08:19 +0200
Message-Id: <200505251708.j4PH8Jb4017205@krt.neobee.net>
Reply-To: <mile.davidovic@micronasnit.com>
From:	"Mile Davidovic" <mile.davidovic@micronasnit.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Mips4KECR2
Date:	Wed, 25 May 2005 18:00:32 +0200
Organization: MicronasNIT
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVhQuDYchYJkAONS9WjBRBe+vSwhA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Virus-Scanned: by amavisd-new at krt.neobee.net
Return-Path: <mile.davidovic@micronasnit.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7976
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mile.davidovic@micronasnit.com
Precedence: bulk
X-list: linux-mips

Hello all 

I have problem with MIPS4KECR2 and int handler, MIPS 4KECR2 has support for
external interrupt controller. 
AFAIK, conditions for EIC mode are next:
	Config3(VEIC) = 1
	IntCtl(VS) != 0
	Cause(IV) = 1
	Status(BEV) = 0

IntCtl(VS) has to be different then zero and this field specifies spacing
beetween vectored interrupts.
Interrupt handler for MIPS4KECR2 is placed on 0x80000200 and if I set
IntCtl(VS) on 0x20 and I want to
use max number of interrupts (63) I have to place almost 2k from 0x80000200
and I am afraid that I will
overwritten something.

I am pretty shure that I do not see obviouse things, but any help/comment
will be most welcome.


Best regards Mile


From haukeh@pc-kiel.de Thu May 26 14:20:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 14:20:34 +0100 (BST)
Received: from natfrord.rzone.de ([IPv6:::ffff:81.169.145.161]:41156 "EHLO
	natfrord.rzone.de") by linux-mips.org with ESMTP
	id <S8225942AbVEZNUR>; Thu, 26 May 2005 14:20:17 +0100
Received: from tux04 (p548D6BF1.dip.t-dialin.net [84.141.107.241])
	by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j4QDKFEw004635
	for <linux-mips@linux-mips.org>; Thu, 26 May 2005 15:20:16 +0200 (MEST)
From:	Hauke Goos-Habermann <haukeh@pc-kiel.de>
To:	linux-mips@linux-mips.org
Subject: CCA4 mapping
Date:	Thu, 26 May 2005 15:20:34 +0200
User-Agent: KMail/1.7.2
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505261520.34985.haukeh@pc-kiel.de>
Return-Path: <haukeh@pc-kiel.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7977
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: haukeh@pc-kiel.de
Precedence: bulk
X-list: linux-mips

Hi all,

I'm trying to make a mapping (with burst mode (CCA4)) from the graphic card 
memory to the virtual memory space.

I used the __ioremap with different parameters without success.

The grafic card memory is 64MB, and can be found at 0x00800000 and should be 
mapped to a memory space that can be accessed via a kernel module or via user 
space.

I tried the following mapping:

add_wired_entry((0x00800000 >> 2) | 0x0027, (0x00900000 >> 2) | 0x0027, 
0x30000000 | 0x0027, 0x01ffe000);
add_wired_entry((0x00a00000 >> 2) | 0x0027, (0x00a00000 >> 2) | 0x0027, 
0x32000000 | 0x0027, 0x01ffe000);

This doesn't work either.

Does anybody have an idea how to make the CCA4 mapping?

Cu Hauke

From yuasa@hh.iij4u.or.jp Thu May 26 15:51:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 15:51:47 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:19193 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225960AbVEZOvc>;
	Thu, 26 May 2005 15:51:32 +0100
Received: MO(mo01) for <linux-mips@linux-mips.org> id j4QEpSLG028800; Thu, 26 May 2005 23:51:28 +0900 (JST)
Received: MDO(mdo01) id j4QEpSpr003479; Thu, 26 May 2005 23:51:28 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j4QEpQMU016710
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT)
	for <linux-mips@linux-mips.org>; Thu, 26 May 2005 23:51:27 +0900 (JST)
Date:	Thu, 26 May 2005 23:51:25 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	linux-mips <linux-mips@linux-mips.org>
Subject: [RFC] remove NEC Osprey
Message-Id: <20050526235125.636bd22a.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7978
X-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,

I think that NEC Osprey is not maintained on v2.6.
If there is no objection, I'll send a patch for removing NEC Osprey next week.

Thanks,

Yoichi

From maxim.osipov@gmail.com Thu May 26 17:33:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 17:33:23 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.203]:38851 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8225973AbVEZQdH> convert rfc822-to-8bit;
	Thu, 26 May 2005 17:33:07 +0100
Received: by zproxy.gmail.com with SMTP id 13so985490nzp
        for <linux-mips@linux-mips.org>; Thu, 26 May 2005 09:33:00 -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:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=PMEPd7e5R/hpq0jXhli9HjXLJ+fN3AEBqg8prqRQL/HFsnUcAbNlr/PSv6Luoc3ihi9f5c1gCFCDI2KBgTiQWxO2Hl6EkEXh6j68kbFL3A4LmlPpQeL34XWKjLD1sUNFI7adokq/Few6dQiFLJGTqIxdj21skEDmCd0GToAafM4=
Received: by 10.36.71.16 with SMTP id t16mr703149nza;
        Thu, 26 May 2005 09:32:59 -0700 (PDT)
Received: by 10.36.68.6 with HTTP; Thu, 26 May 2005 09:32:59 -0700 (PDT)
Message-ID: <6097c4905052609326a4c1232@mail.gmail.com>
Date:	Thu, 26 May 2005 20:32:59 +0400
From:	Maxim Osipov <maxim.osipov@gmail.com>
Reply-To: maxim@mox.ru
To:	linux-mips@linux-mips.org
Subject: glibc-2.3.4 mips64 compilation failure
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <maxim.osipov@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7979
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maxim.osipov@gmail.com
Precedence: bulk
X-list: linux-mips

Hello,

I am trying to build glibc-2.3.4 using binutils-2.15 and gcc-3.4.3
from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux.
Compilation fails with following messages:

clude/libc-symbols.h -DPIC -DASSEMBLER -x assembler-with-cpp -o
/home/maxim/temp/build-glibc/io/sendfile.o -
.././scripts/mkinstalldirs /home/maxim/temp/build-glibc/io
(echo '#include <sysdep.h>'; \
 echo 'PSEUDO (sendfile64, sendfile64, 4)'; \
 echo ' ret'; \
 echo 'PSEUDO_END(sendfile64)'; \
 echo 'libc_hidden_def (sendfile64)'; \
) | mips64-linux-gcc -mabi=64 -c -I../include -I.
-I/home/maxim/temp/build-glibc/io -I.. -I../libio
-I/home/maxim/temp/build-glibc -I../sysdeps/mips/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/mips/mips64
-I../linuxthreads/sysdeps/unix/sysv/linux/mips
-I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/mips
-I../sysdeps/unix/sysv/linux/mips/mips64/n64
-I../sysdeps/unix/sysv/linux/mips/mips64
-I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/mips/mips64/n64 -I../sysdeps/unix/mips/mips64
-I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/mips/mips64/n64 -I../sysdeps/ieee754/ldbl-128
-I../sysdeps/mips/mips64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/mips -I../sysdeps/wordsize-64
-I../sysdeps/mips/fpu -I../sysdeps/ieee754 -I../sysdeps/generic/elf
-I../sysdeps/generic -nostdinc -isystem
/usr/lib/gcc/mips64-linux/3.4.3/include -isystem
/usr/local/tools/mips64-linux/mips64-linux/sys-root/usr/include
-D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DASSEMBLER
-x assembler-with-cpp -o /home/maxim/temp/build-glibc/io/sendfile64.o
-
<stdin>: Assembler messages:
<stdin>:2: Error: absolute expression required `li'
make[2]: *** [/home/maxim/temp/build-glibc/io/sendfile64.o] Error 1
make[2]: Leaving directory `/home/maxim/temp/glibc-2.3.4/io'
make[1]: *** [io/subdir_lib] Error 2
make[1]: Leaving directory `/home/maxim/temp/glibc-2.3.4'

Has anyone seen it before? And one more thing - are there srpms for
the above mentioned tools available?

Best regards,
Maxim

From drow@nevyn.them.org Thu May 26 18:06:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 18:06:25 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:30369 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225976AbVEZRGJ>;
	Thu, 26 May 2005 18:06:09 +0100
Received: from drow by nevyn.them.org with local (Exim 4.50)
	id 1DbLo3-0003ST-Qq; Thu, 26 May 2005 13:06:03 -0400
Date:	Thu, 26 May 2005 13:06:03 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	maxim@mox.ru
Cc:	linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
Message-ID: <20050526170603.GA13272@nevyn.them.org>
References: <6097c4905052609326a4c1232@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6097c4905052609326a4c1232@mail.gmail.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7980
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Thu, May 26, 2005 at 08:32:59PM +0400, Maxim Osipov wrote:
> Hello,
> 
> I am trying to build glibc-2.3.4 using binutils-2.15 and gcc-3.4.3
> from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux.
> Compilation fails with following messages:

Looks like your kernel headers are too old.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

From macro@linux-mips.org Thu May 26 18:26:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 18:26:24 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:59142 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225978AbVEZR0I>; Thu, 26 May 2005 18:26:08 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 8FDE4E1C7C; Thu, 26 May 2005 19:25:56 +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 06876-04; Thu, 26 May 2005 19:25:56 +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 5A2CAE1C79; Thu, 26 May 2005 19:25:56 +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 j4QHQ0Hr002689;
	Thu, 26 May 2005 19:26:01 +0200
Date:	Thu, 26 May 2005 18:26:10 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
In-Reply-To: <20050526170603.GA13272@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/894/Wed May 25 14:53:16 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7981
X-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 Thu, 26 May 2005, Daniel Jacobowitz wrote:

> > I am trying to build glibc-2.3.4 using binutils-2.15 and gcc-3.4.3
> > from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux.
> > Compilation fails with following messages:
> 
> Looks like your kernel headers are too old.

 Or too new, sigh...  See: 
"http://sources.redhat.com/bugzilla/show_bug.cgi?id=758".  Unfortunately 
it's not clear to me what "the 2.3 branch inclusion criteria" are and it's 
a pity the MIPS port of glibc is unmaintained these days...

  Maciej

From belamina1@yahoo.com Thu May 26 19:59:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 19:59:56 +0100 (BST)
Received: from web32510.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.220]:338
	"HELO web32510.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225995AbVEZS7i>; Thu, 26 May 2005 19:59:38 +0100
Received: (qmail 58039 invoked by uid 60001); 26 May 2005 18:59:31 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=CvfWttYEJdCum2WwOocD/uLP8D0TTinQeAze1ePT3sTBq2ahs2J1dBMM9Ph5id7iQjBp6tbN+cLcCKy9hWmL3hTZGupeilphZTv5K9KsQ44sYH5QbVRT3XQy9LreZ4DBeFMLILRNgU5Pb5vaIpe6xck2oNSFGakXStpICjb/jBE=  ;
Message-ID: <20050526185931.58037.qmail@web32510.mail.mud.yahoo.com>
Received: from [217.132.178.211] by web32510.mail.mud.yahoo.com via HTTP; Thu, 26 May 2005 11:59:31 PDT
Date:	Thu, 26 May 2005 11:59:31 -0700 (PDT)
From:	Michael Belamina <belamina1@yahoo.com>
Subject: Re: 64 bit kernel for BCM1250
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <belamina1@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7982
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: belamina1@yahoo.com
Precedence: bulk
X-list: linux-mips


I have tried the patch on kernel version 2.4.28 and it
seems that the fix is not working for this kernel
version. I used gcc version 2.95.4 and it is working. 

Another questions:

 I am using 32 bit application and 64 bit device
driver that I wrote. ioctl fails with "unknown ioctl"
message. 

1. What is the best way to translate 32 bit ioctl
codes to 64 bit?

2. How 64 bit kernel space buffers will  be used by a
32 bit application (using mmap)? 

3.What is the maximum usable ram out of 2GB I will
have if I am using a 32 bit application and 64 bit
kernel and the kernel is allocating the buffers using
__get_free_pages (I need the buffers for DMA - and I
need them to be physically continuous)?

Thanks,
 Michael








--- "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> On Thu, 19 May 2005, Michael Belamina wrote:
> 
> >    I am still not sure about the following:
> > 
> >    1. Is this problem related only to kernels
> > downloaded from linux-mips.org or it is a more
> general
> > one?
> 
>  The problem is Linux 2.4 is generally in the
> maintenance mode, which 
> means no new development is done on it (although
> still an occasional 
> backport from 2.6 may happen).  As a result
> maintainers are rather 
> hesitant about applying changes unless they fix
> critical bugs.  Bugs 
> revealed by new versions of build tools are not
> usually considered as 
> critical, because you may work them around by using
> an old version of the 
> triggering tool.
> 
>  Still for the MIPS port what you can get from
> linux-mips.org is probably 
> less behind than what there is at kernel.org.
> 
> >    2. Can someone point to a known to work 64 bit
> > versions of gcc and binutil for BCM1250 (the
> problem
> > that started this thread was actually a problem of
> the
> > mip64-linux-ld I was using).
> 
>  For 64-bit builds you probably want to use fairly
> recent versions or you 
> risk hitting serious bugs that used to exist in
> older versions.  Using 
> David's patch (or preferably mine ;-) -- as
> available here: 
>
"http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.55.0406281509170.23162%40jurand.ds.pg.gda.pl";
> 
> which I keep using with GCC 4.0.0) is probably the
> lesser evil.
> 
>   Maciej
> 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

From drow@nevyn.them.org Thu May 26 20:05:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 20:06:14 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:11956 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225985AbVEZTF7>;
	Thu, 26 May 2005 20:05:59 +0100
Received: from drow by nevyn.them.org with local (Exim 4.50)
	id 1DbNg2-0004NS-K8; Thu, 26 May 2005 15:05:54 -0400
Date:	Thu, 26 May 2005 15:05:54 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
Message-ID: <20050526190554.GA16765@nevyn.them.org>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org> <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7983
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Thu, May 26, 2005 at 06:26:10PM +0100, Maciej W. Rozycki wrote:
> On Thu, 26 May 2005, Daniel Jacobowitz wrote:
> 
> > > I am trying to build glibc-2.3.4 using binutils-2.15 and gcc-3.4.3
> > > from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux.
> > > Compilation fails with following messages:
> > 
> > Looks like your kernel headers are too old.
> 
>  Or too new, sigh...  See: 
> "http://sources.redhat.com/bugzilla/show_bug.cgi?id=758".  Unfortunately 
> it's not clear to me what "the 2.3 branch inclusion criteria" are and it's 
> a pity the MIPS port of glibc is unmaintained these days...

He did post the criteria.  You can find them in the list archives
though I don't have a URL handy.

I'm hoping to improve the maintenance in the near future.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From macro@linux-mips.org Thu May 26 20:34:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 20:34:35 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:62990 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225988AbVEZTeU>; Thu, 26 May 2005 20:34:20 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 9B0CBF59BD; Thu, 26 May 2005 21:34: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 06418-02; Thu, 26 May 2005 21:34: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 53DB6F59B7; Thu, 26 May 2005 21:34: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 j4QJYH7Q007728;
	Thu, 26 May 2005 21:34:17 +0200
Date:	Thu, 26 May 2005 20:34:28 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
In-Reply-To: <20050526190554.GA16765@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org>
 <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
 <20050526190554.GA16765@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/894/Wed May 25 14:53:16 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7984
X-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 Thu, 26 May 2005, Daniel Jacobowitz wrote:

> >  Or too new, sigh...  See: 
> > "http://sources.redhat.com/bugzilla/show_bug.cgi?id=758".  Unfortunately 
> > it's not clear to me what "the 2.3 branch inclusion criteria" are and it's 
> > a pity the MIPS port of glibc is unmaintained these days...
> 
> He did post the criteria.  You can find them in the list archives
> though I don't have a URL handy.

 Well, the criteria probably don't change that much if at all from one 
stable branch to another, so having them somewhere at one of the GNU libc 
web pages (probably the sourceware's is the right one for such internal 
guidelines) wouldn't hurt, like it's done e.g. with GCC.  I can't recall 
if I tried searching the mailing list previously, but now "branch 
inclusion criteria" doesn't return anything, so even your hint isn't 
especially useful (and I don't want to spend my life digging the archives, 
sorry).  I'm somewhat surprised, actually, as I'm subscribed to the 
libc-alpha list for quite some time now, certainly since before the branch 
was created and I haven't noticed such an announcement.

> I'm hoping to improve the maintenance in the near future.

 Well, if you have resources for doing that, it will be most welcomed.

  Maciej

From dan@embeddedalley.com Thu May 26 20:39:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 20:40:09 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:56333 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8225988AbVEZTjy>; Thu, 26 May 2005 20:39:54 +0100
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j4QJVA8U001728;
	Thu, 26 May 2005 15:31:11 -0400
In-Reply-To: <200505261520.34985.haukeh@pc-kiel.de>
References: <200505261520.34985.haukeh@pc-kiel.de>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <530c77f53c1c8706d6fd75a07ad091ca@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: CCA4 mapping
Date:	Thu, 26 May 2005 15:39:49 -0400
To:	Hauke Goos-Habermann <haukeh@pc-kiel.de>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7985
X-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 May 26, 2005, at 9:20 AM, Hauke Goos-Habermann wrote:

> Does anybody have an idea how to make the CCA4 mapping?

In the mmap() entry for the driver:

	pgprot_val(vma->vm_page_prot) |= (4 << 9);	/* CCA4 */

or, whatever is appropriate.  This will only work from a user
application (like X-Windows) that mmaps() the driver, you
aren't going to get a kernel mapped space this way without
some special VM space hacking.

Thanks.

	-- Dan


From drow@nevyn.them.org Thu May 26 21:08:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 21:08:28 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:38799 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225991AbVEZUIL>;
	Thu, 26 May 2005 21:08:11 +0100
Received: from drow by nevyn.them.org with local (Exim 4.50)
	id 1DbOeC-0004sO-Og; Thu, 26 May 2005 16:08:04 -0400
Date:	Thu, 26 May 2005 16:08:04 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
Message-ID: <20050526200804.GA18695@nevyn.them.org>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org> <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl> <20050526190554.GA16765@nevyn.them.org> <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7986
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Thu, May 26, 2005 at 08:34:28PM +0100, Maciej W. Rozycki wrote:
> if I tried searching the mailing list previously, but now "branch 
> inclusion criteria" doesn't return anything, so even your hint isn't 
> especially useful (and I don't want to spend my life digging the archives, 
> sorry).  I'm somewhat surprised, actually, as I'm subscribed to the 
> libc-alpha list for quite some time now, certainly since before the branch 
> was created and I haven't noticed such an announcement.

It's buried in:
  http://sourceware.org/ml/libc-alpha/2004-12/msg00063.html

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From drow@nevyn.them.org Thu May 26 21:15:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 21:15:19 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:24026 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225991AbVEZUPF>;
	Thu, 26 May 2005 21:15:05 +0100
Received: from drow by nevyn.them.org with local (Exim 4.50)
	id 1DbOkx-0004xD-4N; Thu, 26 May 2005 16:15:03 -0400
Date:	Thu, 26 May 2005 16:15:03 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
Message-ID: <20050526201503.GA19015@nevyn.them.org>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org> <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl> <20050526190554.GA16765@nevyn.them.org> <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl> <20050526200804.GA18695@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050526200804.GA18695@nevyn.them.org>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7987
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Thu, May 26, 2005 at 04:08:04PM -0400, Daniel Jacobowitz wrote:
> On Thu, May 26, 2005 at 08:34:28PM +0100, Maciej W. Rozycki wrote:
> > if I tried searching the mailing list previously, but now "branch 
> > inclusion criteria" doesn't return anything, so even your hint isn't 
> > especially useful (and I don't want to spend my life digging the archives, 
> > sorry).  I'm somewhat surprised, actually, as I'm subscribed to the 
> > libc-alpha list for quite some time now, certainly since before the branch 
> > was created and I haven't noticed such an announcement.
> 
> It's buried in:
>   http://sourceware.org/ml/libc-alpha/2004-12/msg00063.html

... not that those will be very useful to you, unless you want to
suddenly become Fedora.  They'll only be useful to Debian once in a
blue moon.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From macro@linux-mips.org Thu May 26 21:22:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 21:22:56 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:55565 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225991AbVEZUWk>; Thu, 26 May 2005 21:22:40 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 85BBAF5998; Thu, 26 May 2005 22:22:32 +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 32293-08; Thu, 26 May 2005 22:22:32 +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 37C80E1C8E; Thu, 26 May 2005 22:22:32 +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 j4QKMahZ009490;
	Thu, 26 May 2005 22:22:37 +0200
Date:	Thu, 26 May 2005 21:22:47 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
In-Reply-To: <20050526201503.GA19015@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0505262118310.29423@blysk.ds.pg.gda.pl>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org>
 <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
 <20050526190554.GA16765@nevyn.them.org> <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl>
 <20050526200804.GA18695@nevyn.them.org> <20050526201503.GA19015@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/894/Wed May 25 14:53:16 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7988
X-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 Thu, 26 May 2005, Daniel Jacobowitz wrote:

> > It's buried in:
> >   http://sourceware.org/ml/libc-alpha/2004-12/msg00063.html
> 
> ... not that those will be very useful to you, unless you want to
> suddenly become Fedora.  They'll only be useful to Debian once in a
> blue moon.

 Thanks for the link and indeed -- I don't think we have any setup 
available that would qualify as a "distribution" as referred to by the 
rules.  Especially as for MIPS you'd have to multiply that by three for 
the supported ABIs.

 As a result we have no glibc release that would work for a reasonably 
modern setup of MIPS/Linux.

  Maciej

From drow@nevyn.them.org Thu May 26 21:24:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 21:24:31 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:984 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225991AbVEZUYR>;
	Thu, 26 May 2005 21:24:17 +0100
Received: from drow by nevyn.them.org with local (Exim 4.50)
	id 1DbOtr-000526-3u; Thu, 26 May 2005 16:24:15 -0400
Date:	Thu, 26 May 2005 16:24:15 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
Message-ID: <20050526202415.GA19298@nevyn.them.org>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org> <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl> <20050526190554.GA16765@nevyn.them.org> <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl> <20050526200804.GA18695@nevyn.them.org> <20050526201503.GA19015@nevyn.them.org> <Pine.LNX.4.61L.0505262118310.29423@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0505262118310.29423@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7989
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Thu, May 26, 2005 at 09:22:47PM +0100, Maciej W. Rozycki wrote:
> On Thu, 26 May 2005, Daniel Jacobowitz wrote:
> 
> > > It's buried in:
> > >   http://sourceware.org/ml/libc-alpha/2004-12/msg00063.html
> > 
> > ... not that those will be very useful to you, unless you want to
> > suddenly become Fedora.  They'll only be useful to Debian once in a
> > blue moon.
> 
>  Thanks for the link and indeed -- I don't think we have any setup 
> available that would qualify as a "distribution" as referred to by the 
> rules.  Especially as for MIPS you'd have to multiply that by three for 
> the supported ABIs.
> 
>  As a result we have no glibc release that would work for a reasonably 
> modern setup of MIPS/Linux.

HEAD does work, however.  I will even get around to the MIPS64 NPTL
bits for HEAD very soon.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From macro@linux-mips.org Thu May 26 21:33:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 May 2005 21:33:58 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:44046 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225991AbVEZUdo>; Thu, 26 May 2005 21:33:44 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 394EBF59B4; Thu, 26 May 2005 22:33:32 +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 07063-01; Thu, 26 May 2005 22:33:32 +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 F2D01F5998; Thu, 26 May 2005 22:33:31 +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 j4QKXbcP009844;
	Thu, 26 May 2005 22:33:37 +0200
Date:	Thu, 26 May 2005 21:33:49 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	maxim@mox.ru, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
In-Reply-To: <20050526202415.GA19298@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0505262125320.29423@blysk.ds.pg.gda.pl>
References: <6097c4905052609326a4c1232@mail.gmail.com> <20050526170603.GA13272@nevyn.them.org>
 <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
 <20050526190554.GA16765@nevyn.them.org> <Pine.LNX.4.61L.0505262023030.29423@blysk.ds.pg.gda.pl>
 <20050526200804.GA18695@nevyn.them.org> <20050526201503.GA19015@nevyn.them.org>
 <Pine.LNX.4.61L.0505262118310.29423@blysk.ds.pg.gda.pl>
 <20050526202415.GA19298@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.83/894/Wed May 25 14:53:16 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7990
X-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 Thu, 26 May 2005, Daniel Jacobowitz wrote:

> HEAD does work, however.  I will even get around to the MIPS64 NPTL
> bits for HEAD very soon.

 Hmm, has #933 been applied to HEAD?  Apparently not.  I have more stuff 
to come that's less obvious, but what's the point if even basic one is 
stuck?  I put such bits at my FTP site of course, so that people can still 
benefit.

  Maciej

From developer@phatlinux.com Fri May 27 04:11:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 04:11:48 +0100 (BST)
Received: from server256.com ([IPv6:::ffff:202.85.141.143]:10918 "HELO
	server256.com") by linux-mips.org with SMTP id <S8224937AbVE0DL3>;
	Fri, 27 May 2005 04:11:29 +0100
Received: (qmail 14699 invoked by uid 512); 27 May 2005 03:11:23 -0000
Message-ID: <20050527031123.1327.qmail@server256.com>
Reply-To: "developer" <developer@phatlinux.com>
From:	"developer" <developer@phatlinux.com>
To:	linux-mips@linux-mips.org
Subject: Porting To New System
Date:	Fri, 27 May 2005 03:11:23 
MIME-Version: 1.0
X-Mailer: WebMail 2.0
X-Originating-IP: 65.24.168.255
X-Originating-Email: developer@phatlinux.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7991
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

Hello all,

I'm a long time Linux user, and computer engineering student. I've recently become interested in porting Linux to Sony's PSP gaming system. I'm wanting to do this mainly as an exercise in understanding the kernel better, also I just think it would be neat :). The PSP system has a MIPS R4000 CPU which is already supported so it is my understanding that the port should not be so difficult, not to say that I think it will be easy. At this time I have a gcc toolchain set up which allows me to write and execute code on the PSP, however I have never attempted a kernel port so I'm a little unsure on what to do. I'm looking for someone who wouldn't mind assisting me with my project by helping me with my questions on the porting process. I you have time to answer a few emails here and there, and would like to help me, I would greatly appreciate it.

Thanks,
Cameron Cooper

From sskowron@ET.PUT.Poznan.PL Fri May 27 05:37:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 05:37:57 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:2036 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225207AbVE0Ehk>; Fri, 27 May 2005 05:37:40 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4R4bae20548;
	Fri, 27 May 2005 06:37:37 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 27 May 2005 06:37:35 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4R4bYP21333;
	Fri, 27 May 2005 06:37:34 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Fri, 27 May 2005 06:37:34 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	developer <developer@phatlinux.com>
cc:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
In-Reply-To: <20050527031123.1327.qmail@server256.com>
Message-ID: <Pine.GSO.4.10.10505270556110.19477-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7992
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

First, does the PSP's processor have a MMU? If not, then there is not much
point in porting Linux (or for that matter, anything else). A machine
without a MMU is pretty worthless under Linux except as a fixed-function
embedded system; to wit, mmap(2) will not work.

Next, see http://www.linux-mips.org/wiki/index.php/Porting - it's
excellent. I don't know if a PSP has an accessible serial port - if not,
then you are somewhat screwed (OK, so not that bad; I've done a port that
used graphical display from the beginning for all debugging purposes).

You've got to do three things:
 1) use lines no longer than 80 chars in your mails ;)
 2) get all docs on the PSP you can get - reverse engineering is fun but
    only if you enjoy hacking for 14 hours a day,
 3) take a look at some directory in arch/mips.

Of course, the hardest of them is (2) in my experience, unless Sony felt
generous at the time and released all PSP docs. My port was completely
reverse-engineered but I wouldn't advise to do that unless you are sure
you can spare the time and effort.

Oh, and one more thing: USE THE CVS LINUX-MIPS.ORG TREE! The kernel.org
tree is so out of sync that it's virtually worthless.

Cheers,

Stanislaw Skowronek



From ed@okerson.com Fri May 27 06:10:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 06:11:03 +0100 (BST)
Received: from 69-149-250-3.ded.swbell.net ([IPv6:::ffff:69.149.250.3]:45741
	"EHLO optic.calpha.com") by linux-mips.org with ESMTP
	id <S8225249AbVE0FKq>; Fri, 27 May 2005 06:10:46 +0100
Received: from mail.okerson.com (optic [127.0.0.1])
	by optic.calpha.com (8.12.11/8.12.11) with ESMTP id j4R5DuVF025993
	for <linux-mips@linux-mips.org>; Fri, 27 May 2005 00:13:57 -0500
Received: from 66.93.44.28
        (SquirrelMail authenticated user ed);
        by mail.okerson.com with HTTP;
        Thu, 26 May 2005 22:13:57 -0700 (PDT)
Message-ID: <4592.66.93.44.28.1117170837.squirrel@66.93.44.28>
In-Reply-To: <20050527031123.1327.qmail@server256.com>
References: <20050527031123.1327.qmail@server256.com>
Date:	Thu, 26 May 2005 22:13:57 -0700 (PDT)
Subject: Re: Porting To New System
From:	"Ed Okerson" <ed@okerson.com>
To:	linux-mips@linux-mips.org
User-Agent: SquirrelMail/1.4.3a
X-Mailer: SquirrelMail/1.4.3a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Return-Path: <ed@okerson.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7993
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ed@okerson.com
Precedence: bulk
X-list: linux-mips

> Hello all,
>
> I'm a long time Linux user, and computer engineering student. I've
> recently become interested in porting Linux to Sony's PSP gaming system.
> I'm wanting to do this mainly as an exercise in understanding the kernel
> better, also I just think it would be neat :). The PSP system has a MIPS
> R4000 CPU which is already supported so it is my understanding that the
> port should not be so difficult, not to say that I think it will be easy.
> At this time I have a gcc toolchain set up which allows me to write and
> execute code on the PSP, however I have never attempted a kernel port so
> I'm a little unsure on what to do. I'm looking for someone who wouldn't
> mind assisting me with my project by helping me with my questions on the
> porting process. I you have time to answer a few emails here and there,
> and would like to help me, I would greatly appreciate it.

You should probably have a look at http://www.psp-linux.org/ click on
messages boards at the top of the page to get to all the action.  I am
sure these guys can answer all your questions.

Ed Okerson




From sskowron@ET.PUT.Poznan.PL Fri May 27 06:40:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 06:40:46 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:21929
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224921AbVE0Fk3>; Fri, 27 May 2005 06:40:29 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4R5eO215990
	for <linux-mips@linux-mips.org>; Fri, 27 May 2005 07:40:24 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 27 May 2005 07:40:24 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4R5eN123930
	for <linux-mips@linux-mips.org>; Fri, 27 May 2005 07:40:23 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Fri, 27 May 2005 07:40:23 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
In-Reply-To: <4592.66.93.44.28.1117170837.squirrel@66.93.44.28>
Message-ID: <Pine.GSO.4.10.10505270720390.23050-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7994
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> You should probably have a look at http://www.psp-linux.org/ click on
> messages boards at the top of the page to get to all the action.  I am
> sure these guys can answer all your questions.

Hurm, hurm. I think that the closed-circle development model is, uhm, less
efficient - there are no tech info on the forums which means nobody can
try and follow. They just finished organizing themselves, and it took them
*three months*. Three months wasted on choosing developers. He he he.

That said, they have really hard work to do - I wish them all the luck
they need, which is *a lot*. Cracking locked-down systems with proprietary
formats is incredibly hard. It's hard enough when they aren't proprietary,
or when they aren't deliberately locked-down.

Stanislaw Skowronek

PS. There are also some funny things there, like "Off-Topic: please keep
related to the PSP". Maybe I'm just an anal-retentive paranoid (OK, I know
I am), but when I see something like that I feel put upon. It's like all
those "keep off the grass" and "private property, survivors will be shot
again" signs. Placed in the middle of Sahara.



From kumba@gentoo.org Fri May 27 07:19:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 07:20:03 +0100 (BST)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:5809 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225987AbVE0GTr>; Fri, 27 May 2005 07:19:47 +0100
Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45])
          by comcast.net (sccrmhc12) with ESMTP
          id <2005052706194001200ha7i2e>; Fri, 27 May 2005 06:19:40 +0000
Message-ID: <4296BCA3.7040003@gentoo.org>
Date:	Fri, 27 May 2005 02:22:27 -0400
From:	Kumba <kumba@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
References: <Pine.GSO.4.10.10505270720390.23050-100000@helios.et.put.poznan.pl>
In-Reply-To: <Pine.GSO.4.10.10505270720390.23050-100000@helios.et.put.poznan.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7995
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Stanislaw Skowronek wrote:
> 
> That said, they have really hard work to do - I wish them all the luck
> they need, which is *a lot*. Cracking locked-down systems with proprietary
> formats is incredibly hard. It's hard enough when they aren't proprietary,
> or when they aren't deliberately locked-down.

With this in mind, I'm watching the port of Linux to the Nintendo DS.  They 
apparently just got 2.6 and framebuffer working, so it'll be interesting to see 
where they go with it.  Given the DS is a far more constrained system, and 
Nintendo not very forthcoming on their hardware specs, I'm surprised at the 
speed with which they've gotten things working.

And PSP isn't entirely closed -- it is based to a certain degree off PS2 
hardware, of which Sony release 6 of a supposed 7 total technical documents 
regarding the innards of the system.  Now I imagine alot of the custom hacks 
needed to support the R5900 in PS2 aren't needed in PSP, since it uses a more 
standard CPU, this might have an impact on how fast or slow they wind up porting 
the kernel.


--Kumba

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

From maxim.osipov@gmail.com Fri May 27 11:15:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 11:15:40 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.198]:53850 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8226025AbVE0KPV> convert rfc822-to-8bit;
	Fri, 27 May 2005 11:15:21 +0100
Received: by zproxy.gmail.com with SMTP id 13so1390249nzp
        for <linux-mips@linux-mips.org>; Fri, 27 May 2005 03:15: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=jy4nJr/yDJe+E1jiVaWCSxITziao/z6CWBsVGqakyU7dnxrn/iugAc65+hxikHEhwCTYTT0Ibmy5AK/2KSY3HAw/s7pci/SzoFO0aF2mbu4pY343IuA9T1JFeyNfQUnd5+KNRRN2ssqynWFR5sL9xXfZNXPJ5ju3B/bKfBF/z2Y=
Received: by 10.36.55.20 with SMTP id d20mr977475nza;
        Fri, 27 May 2005 03:15:13 -0700 (PDT)
Received: by 10.36.68.6 with HTTP; Fri, 27 May 2005 03:15:13 -0700 (PDT)
Message-ID: <6097c4905052703152b50f717@mail.gmail.com>
Date:	Fri, 27 May 2005 14:15:13 +0400
From:	Maxim Osipov <maxim.osipov@gmail.com>
Reply-To: maxim@mox.ru
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: glibc-2.3.4 mips64 compilation failure
Cc:	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org
In-Reply-To: <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <6097c4905052609326a4c1232@mail.gmail.com>
	 <20050526170603.GA13272@nevyn.them.org>
	 <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
Return-Path: <maxim.osipov@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7996
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maxim.osipov@gmail.com
Precedence: bulk
X-list: linux-mips

Hmm... I don't know. Both 2.4.26 and 2.6.10 headers do not contain
this call number in unistd.h for N64, but glibc tries to generate a
stub referencing to undefined __NR_sendfile64, and I got this
assembler error.

I tried various kernel/glibc configurations and result is the same -
we fail on sendfile64 or time.

Do anyone have a clue what is happening? AFAIK, some people already
had success building glibc for mips64. Probably I miss something?

Best regards,
Maxim


On 5/26/05, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Thu, 26 May 2005, Daniel Jacobowitz wrote:
> 
> > > I am trying to build glibc-2.3.4 using binutils-2.15 and gcc-3.4.3
> > > from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux.
> > > Compilation fails with following messages:
> >
> > Looks like your kernel headers are too old.
> 
>  Or too new, sigh...  See:
> "http://sources.redhat.com/bugzilla/show_bug.cgi?id=758".  Unfortunately
> it's not clear to me what "the 2.3 branch inclusion criteria" are and it's
> a pity the MIPS port of glibc is unmaintained these days...
> 
>   Maciej
> 
>

From developer@phatlinux.com Fri May 27 17:28:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 17:28:42 +0100 (BST)
Received: from server256.com ([IPv6:::ffff:202.85.141.143]:6080 "HELO
	server256.com") by linux-mips.org with SMTP id <S8226068AbVE0Q2Z>;
	Fri, 27 May 2005 17:28:25 +0100
Received: (qmail 28556 invoked by uid 512); 27 May 2005 16:28:16 -0000
Message-ID: <20050527162816.31998.qmail@server256.com>
Reply-To: "Cameron Cooper" <developer@phatlinux.com>
From:	"Cameron Cooper" <developer@phatlinux.com>
To:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
Date:	Fri, 27 May 2005 16:28:16 +0000
MIME-Version: 1.0
X-Mailer: WebMail 2.0
X-Originating-IP: 128.146.88.154
X-Originating-Email: developer@phatlinux.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7997
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

>  > You should probably have a look at http://www.psp-linux.org/ click on
>  > messages boards at the top of the page to get to all the action.  I am
>  > sure these guys can answer all your questions.
>  
>  Hurm, hurm. I think that the closed-circle development model is, uhm, less
>  efficient - there are no tech info on the forums which means nobody can
>  try and follow. They just finished organizing themselves, and it took them
>  *three months*. Three months wasted on choosing developers. He he he.

That project is pretty much a joke. There is literally no work being done there. After three months of selecting developers they chose 12 people, and of those twelve were me and an application someone submitted under the name Dennis Ritchie. Since they have chosen developers over a month ago, they have not done a single thing. Beyond that, I don't like their closed development model. I have started a Sourceforge project for PSP Linux at psplinux.sf.net .
  
>  That said, they have really hard work to do - I wish them all the luck
>  they need, which is *a lot*. Cracking locked-down systems with proprietary
>  formats is incredibly hard. It's hard enough when they aren't proprietary,
>  or when they aren't deliberately locked-down.

I understand that cracking a closed system is very hard, so I would rather not do it that way. I have never ported a kernel, so I don't know what I will suggest is possable, but it seems like it could be. 

At this time I can write code for the PSP. I have access to the keypad, MemoryStick, and the frame buffer. The programs that I compile can be placed on the memory stick and launched from the PSP's OS. All I/O in the program is done through calls to libraries provided in the firmware, which are part of the PSPs OS. Becuase the PSP makes heavy use of encryption, it has been very hard to reverse engineer the software. We can't simply look at the libraries to understand the hardware better, because they are encrypted. They only way we have been able to discover anything about the libraries is through the small bits of uencrypted code that were extracted from the firmware chip.

What I would like to know is if it would be possable to do what User Mode Linux has done. Would it be possable to run Linux on top of the PSP's current OS, and write drivers for Linux which will use the libraries provided by the firmware? I know that this is not an ideal solution, but when the PSP being as closed as it as, I see it being a very long time until we will know enough about the hardware to do it another way. Mostly because the PSP makes much use of many custom chips and almost every executable is encrypted.

So even if this is a bad way of doing it, is it even possable?

Thanks,
Cameron Cooper

From alan@lxorguk.ukuu.org.uk Fri May 27 17:43:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 17:43:22 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:20154
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8226070AbVE0QnH>; Fri, 27 May 2005 17:43:07 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j4RGfKsc030640;
	Fri, 27 May 2005 17:41:20 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j4RGfGv3030639;
	Fri, 27 May 2005 17:41:16 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Porting To New System
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Cameron Cooper <developer@phatlinux.com>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050527162816.31998.qmail@server256.com>
References: <20050527162816.31998.qmail@server256.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1117212073.5730.221.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Fri, 27 May 2005 17:41:15 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7998
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Gwe, 2005-05-27 at 17:28, Cameron Cooper wrote:
> So even if this is a bad way of doing it, is it even possable?

It's certainly a good way to get started. Several ports began by using
boot firmware drivers and then eventually replaced them.

Does the firmware give you the ability to control MMU mappings ?


From developer@phatlinux.com Fri May 27 18:00:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 18:00:18 +0100 (BST)
Received: from server256.com ([IPv6:::ffff:202.85.141.143]:64948 "HELO
	server256.com") by linux-mips.org with SMTP id <S8226075AbVE0RAD>;
	Fri, 27 May 2005 18:00:03 +0100
Received: (qmail 16408 invoked by uid 512); 27 May 2005 16:59:49 -0000
Message-ID: <20050527165949.17623.qmail@server256.com>
Reply-To: "Cameron Cooper" <developer@phatlinux.com>
From:	"Cameron Cooper" <developer@phatlinux.com>
To:	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	"Cameron Cooper" <developer@phatlinux.com>,
	linux-mips@linux-mips.org
Subject: Re: Porting To New System
Date:	Fri, 27 May 2005 16:59:49 +0000
MIME-Version: 1.0
X-Mailer: WebMail 2.0
X-Originating-IP: 128.146.88.154
X-Originating-Email: developer@phatlinux.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7999
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

>  > So even if this is a bad way of doing it, is it even possable?
>  
>  It's certainly a good way to get started. Several ports began by using
>  boot firmware drivers and then eventually replaced them.
>  
>  Does the firmware give you the ability to control MMU mappings ?

At this time only a few firmware functions are known. Well, to be more exact, only a few are usable. While we know many of the functions provided by the firmware, we do not know many of thier arguments. At this time we know how to maniuplate the frame buffer, read button presses, read/write to the memory stick, and play back audio, but we do not have a way to control MMU mappings. We have only had the ability to write/execute code on the PSP for a month. Discoveries are being made all the time, so we will certainly know more about the firmware in the coming weeks.

From sskowron@ET.PUT.Poznan.PL Fri May 27 18:31:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 18:31:39 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:44175 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226074AbVE0RbY>; Fri, 27 May 2005 18:31:24 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4RHVGe26296;
	Fri, 27 May 2005 19:31:18 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 27 May 2005 19:30:20 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4RHUCT25120;
	Fri, 27 May 2005 19:30:12 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Fri, 27 May 2005 19:30:12 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Cameron Cooper <developer@phatlinux.com>
cc:	Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-mips@linux-mips.org
Subject: Re: Porting To New System
In-Reply-To: <20050527165949.17623.qmail@server256.com>
Message-ID: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8000
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

>  Does the firmware give you the ability to control MMU mappings ?

I think we won't - this would be a serious security bug.

Stanislaw



From alan@lxorguk.ukuu.org.uk Fri May 27 19:14:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 19:15:20 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:36283
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8224769AbVE0SO5>; Fri, 27 May 2005 19:14:57 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j4RID8T6030889;
	Fri, 27 May 2005 19:13:08 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j4RID7JI030888;
	Fri, 27 May 2005 19:13:07 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Porting To New System
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Cameron Cooper <developer@phatlinux.com>, linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1117217584.5743.229.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Fri, 27 May 2005 19:13:07 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8001
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Gwe, 2005-05-27 at 18:30, Stanislaw Skowronek wrote:
> >  Does the firmware give you the ability to control MMU mappings ?
> 
> I think we won't - this would be a serious security bug.

That depends who the device is defending against and how. MMU control
cuts both ways in game consoles (if present) - it makes it harder to
defend the console from a hostile writer, but it also makes it easier
for the game authors to debug and to trap/recover from errors when the
game is deployed.

For ucLinux you essentially need a console, an input device (keyboard
etc), a storage device, the ability to allocate memory and a timer
interrupt/callback. Absolutely everything else is optional. So you can
probably run ucLinux as a 'game' which allocates lots of memory,
requests a timer callback and drives the entire world through the
firmware. Whether you can do non-ucLinux depends on MMU access and
control. If you've got some kind of MMU interface then you've probably
got sufficient to do a full Linux but ucLinux would still be a natural
stepping stone in exploration.

Alan


From developer@phatlinux.com Fri May 27 19:23:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 19:23:37 +0100 (BST)
Received: from ms-smtp-01-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.135]:17837
	"EHLO ms-smtp-01-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8224784AbVE0SXV>; Fri, 27 May 2005 19:23:21 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-01-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4RIMoWY022115;
	Fri, 27 May 2005 14:23:08 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
In-Reply-To: <1117217584.5743.229.camel@localhost.localdomain>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
	 <1117217584.5743.229.camel@localhost.localdomain>
Content-Type: text/plain
Date:	Fri, 27 May 2005 14:21:15 -0400
Message-Id: <1117218075.2921.2.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8002
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

> For ucLinux you essentially need a console, an input device (keyboard
> etc), a storage device, the ability to allocate memory and a timer
> interrupt/callback. Absolutely everything else is optional. So you can
> probably run ucLinux as a 'game' which allocates lots of memory,
> requests a timer callback and drives the entire world through the
> firmware. Whether you can do non-ucLinux depends on MMU access and
> control. If you've got some kind of MMU interface then you've probably
> got sufficient to do a full Linux but ucLinux would still be a natural
> stepping stone in exploration.

Thank you, that is a very useful bit of information. I will start with
ucLinux. Once (if?) a MMU interface is discovered then I will do a full
Linux kernel.

Cameron


From sskowron@ET.PUT.Poznan.PL Fri May 27 20:43:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 20:43:55 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:32149 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8224793AbVE0Tnk>; Fri, 27 May 2005 20:43:40 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4RJhbe27443;
	Fri, 27 May 2005 21:43:37 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 27 May 2005 21:43:34 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4RJhXS02115;
	Fri, 27 May 2005 21:43:33 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Fri, 27 May 2005 21:43:32 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Cameron Cooper <developer@phatlinux.com>
cc:	Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-mips@linux-mips.org
Subject: Re: Porting To New System
In-Reply-To: <1117218075.2921.2.camel@phatbox>
Message-ID: <Pine.GSO.4.10.10505272130200.1499-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8003
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

Rest assured, there will be no MMU interface. The machine is so incredibly
well-locked-down, especially the newer versions, that they must have done
that for a purpose (probably to stop pirated/cracked games from running).

All software that is going to run on the PSP is cryptographically signed
(probably also encrypted). The kernel is signed and encrypted, too. There
were some loopholes in 1.0 but nobody found any in 1.5 or later.

I'd suggest attacking the hardware to see what goes on in SDRAM. This is
going to be (relatively) expensive and (very) complex, and the result is
not guaranteed as there is some embedded DRAM inside the processors
(scary). However, if any kernel code is ever placed in external SDRAM, it
would be pretty doable to subvert it (would require stopping the CPU
accesses to the SDRAM, which we can probably do, more or less - for
instance running in a tight loop will probably place everything, including
parts of the timer IRQ, in cache, so no external accesses will be
happening). We can perform some writes to SDRAM then. I see a problem with
this method that it requires overpowering some signals on the bus.
Alternatively, we might want to multiplex those signals although it's not
gonna be easy with DDR at 100-200 MHz (probably - the routing on PCB looks
vaguely high-speedey and there is a nice differential clock pair, so DDR
is likely, and the memory chip itself is rated 6 ns, so DDR333).

Mucking with DDR is a hell of a job, even if you have really good hardware
at your disposal. I wonder how much would it be possible to slow it down
by changing the clock oscillator (probably less than 2x, unfortunately).
Monitoring DDR333 is doable but it is not easy.

That said, I'm seriously thinking about getting myself a PSP. I've already
got some serious digital hardware...

Hmmm.

Stanislaw



From developer@phatlinux.com Fri May 27 20:54:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 May 2005 20:54:34 +0100 (BST)
Received: from ms-smtp-03-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.137]:32156
	"EHLO ms-smtp-03-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8224808AbVE0TyT>; Fri, 27 May 2005 20:54:19 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-03-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4RJruYF028624;
	Fri, 27 May 2005 15:54:12 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
In-Reply-To: <1117217584.5743.229.camel@localhost.localdomain>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
	 <1117217584.5743.229.camel@localhost.localdomain>
Content-Type: text/plain
Date:	Fri, 27 May 2005 15:52:19 -0400
Message-Id: <1117223539.2921.15.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8004
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips


> For ucLinux you essentially need a console, an input device (keyboard
> etc), a storage device, the ability to allocate memory and a timer
> interrupt/callback. Absolutely everything else is optional. So you can
> probably run ucLinux as a 'game' which allocates lots of memory,
> requests a timer callback and drives the entire world through the
> firmware. Whether you can do non-ucLinux depends on MMU access and
> control. If you've got some kind of MMU interface then you've probably
> got sufficient to do a full Linux but ucLinux would still be a natural
> stepping stone in exploration.

I've looked into using uClinux, and although it appears as though it
does support MIPS, it is very hard to find any information on it. Do you
have any information regarding using uClinux with MIPS?

Thanks,
Cameron Cooper


From alan@lxorguk.ukuu.org.uk Sat May 28 00:14:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 00:15:01 +0100 (BST)
Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:9150 "EHLO
	lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8224893AbVE0XOp>; Sat, 28 May 2005 00:14:45 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j4RNComP031637;
	Sat, 28 May 2005 00:12:50 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j4RNCnd2031636;
	Sat, 28 May 2005 00:12:49 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Porting To New System
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Cameron Cooper <developer@phatlinux.com>, linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.10.10505272130200.1499-100000@helios.et.put.poznan.pl>
References: <Pine.GSO.4.10.10505272130200.1499-100000@helios.et.put.poznan.pl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1117235565.5730.255.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Sat, 28 May 2005 00:12:47 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8005
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Gwe, 2005-05-27 at 20:43, Stanislaw Skowronek wrote:
> Rest assured, there will be no MMU interface. 

You seem remarkably confident for someone who has never taken one apart.
There are numerous ways to present an MMU interface without allowing
arbitary system access providing you do it via the core OS rather than
via the hardware. This is how Xen handles x86 and the same can be done
by other systems.



From alan@lxorguk.ukuu.org.uk Sat May 28 00:42:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 00:42:53 +0100 (BST)
Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:47806 "EHLO
	lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8224922AbVE0Xmi>; Sat, 28 May 2005 00:42:38 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j4RNenDk031720;
	Sat, 28 May 2005 00:40:49 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j4RNenZ6031719;
	Sat, 28 May 2005 00:40:49 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Porting To New System
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Cameron Cooper <developer@phatlinux.com>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
In-Reply-To: <1117223539.2921.15.camel@phatbox>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
	 <1117217584.5743.229.camel@localhost.localdomain>
	 <1117223539.2921.15.camel@phatbox>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1117237244.5744.284.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Sat, 28 May 2005 00:40:46 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8006
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Gwe, 2005-05-27 at 20:52, Cameron Cooper wrote:
> I've looked into using uClinux, and although it appears as though it
> does support MIPS, it is very hard to find any information on it. Do you
> have any information regarding using uClinux with MIPS?

The 2.6 kernel has uclinux merged but that doesn't include MMUless
support at the moment. The 2.4 uclinux tree is seperate and Xiptech
released a set of patches for 2.4.19 for the mmuless mips and for the
ucLibc if the cpu lacks mipsII and FPU instructions.



From sskowron@ET.PUT.Poznan.PL Sat May 28 06:08:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 06:08:24 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:10406 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225195AbVE1FII>; Sat, 28 May 2005 06:08:08 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4S582e01337;
	Sat, 28 May 2005 07:08:02 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 28 May 2005 07:08:00 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4S57vW22240;
	Sat, 28 May 2005 07:07:58 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Sat, 28 May 2005 07:07:57 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:	Cameron Cooper <developer@phatlinux.com>, linux-mips@linux-mips.org
Subject: Re: Porting To New System
In-Reply-To: <1117235565.5730.255.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.10.10505280700460.21819-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8007
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> You seem remarkably confident for someone who has never taken one apart.

Unless it would be very heavily restricted (rather a mmap-style thing than
a real, direct MMU interface) it would be a serious security breach.

OTOH if the assumption is that PSP is always running trusted code, it is
possible that the game can influence the MMU and there are no security
checks at all. I forgot that the whole ability of running untrusted code
on 1.0 was a bug, and not something planned, so interfaces would not need
be so tight.

By the way, all PSPs you can buy now, except early Japanese version, are
1.5 or higher so the whole point of having a MMU interface is moot
because, as of now, you can't run anything on it at all. Not even a hello
world.

Anyway, I'm going to take one apart :)

Stanislaw



From sskowron@ET.PUT.Poznan.PL Sat May 28 08:30:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 08:30:44 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:8873 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225234AbVE1Ha1>; Sat, 28 May 2005 08:30:27 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4S7UOe01942;
	Sat, 28 May 2005 09:30:24 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 28 May 2005 09:30:23 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j4S7ULs26955;
	Sat, 28 May 2005 09:30:22 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Sat, 28 May 2005 09:30:21 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
In-Reply-To: <1117235565.5730.255.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.10.10505280852210.25329-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8008
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

> > Rest assured, there will be no MMU interface. 
> You seem remarkably confident for someone who has never taken one apart.

Hi.

Sorry if you felt it was overconfident. However I can't think of a really
good reason to give developers a MMU interface, and if I was a Sony
designer I would not do anything that might endanger the "trusted system"
position - so the KISS principle would be my guiding light.

Xen-style MMU access is not KISS at all. This is why I think that there
would be no such thing. The DMA is handled by kernel, so no need for
user-level physical memory access. I would assume that the VRAM is
probably constantly mapped in userspace or something like that - in a
gaming system it would be only natural. And so on. Especially, they are
not interested at all in emulators/virtual machines. Communicating with 3D
engine is done by sceGe* functions that take display lists, so you don't
even have to send them by hand. In the leaked parts of SDK there are few
candidates for functions that might influence the MMU (granted, one is
enough).

I would really like to do the h/w hack. It seems that it will be doable
(although not really easy). And having real-time access to external SDRAM
of the PSP might solve most of our problems. There is exactly one trouble:
time (I have the required hardware, and I can do a FPGA design that would
mirror PSP's SDRAM in external memory, and I can find somebody to do the
tricky BGA soldering). But I don't have the time.

The h/w hack would work unless the PSP is capable of decoding code on it's
way from SDRAM to cache (which would be very wasteful, but if they are
really paranoid, quite justified). However, on published block-diagrams,
the crypto hardware is on a DMA bus, and quite far from the DDR SDRAM in
question. Other dire possibility would be of the kernel never being placed
in external memory (always in internal eDRAM). I don't know how to counter
that.

I think the ucLinux way is the best thing to do right now. It will be
quite impressive. Pity 1.5 won't take it :/

Cheers,

Stanislaw

PS. Besides, does taking one apart actually impart any knowledge? I looked
at the photos, if that helps ;)



From info@voda.cz Sat May 28 11:46:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 11:47:19 +0100 (BST)
Received: from gw.voda.cz ([IPv6:::ffff:212.24.154.90]:54434 "EHLO
	smtp.voda.cz") by linux-mips.org with ESMTP id <S8225249AbVE1Kq6>;
	Sat, 28 May 2005 11:46:58 +0100
Received: from localhost (localhost [127.0.0.1])
	by smtp.voda.cz (Postfix) with ESMTP id 711B01D2E2
	for <linux-mips@linux-mips.org>; Sat, 28 May 2005 12:46:55 +0200 (CEST)
Received: from smtp.voda.cz ([127.0.0.1])
 by localhost (gw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 06809-01 for <linux-mips@linux-mips.org>;
 Sat, 28 May 2005 12:46:26 +0200 (CEST)
Received: from [10.1.1.111] (unknown [10.1.1.111])
	by smtp.voda.cz (Postfix) with ESMTP id F11F41D5B9
	for <linux-mips@linux-mips.org>; Sat, 28 May 2005 12:46:20 +0200 (CEST)
Message-ID: <42984BFC.3000800@voda.cz>
Date:	Sat, 28 May 2005 12:46:20 +0200
From:	VODA IT <info@voda.cz>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Kernel crash in ip_nat on ADM5120
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at voda.cz
Return-Path: <info@voda.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8009
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: info@voda.cz
Precedence: bulk
X-list: linux-mips

Hello,

I get following problem using the 2.6.11 kernel on ADM5120 platform:
Under heavy network load (ie. flood ping) the kernel crashes in NAT (no 
nat is done actually), removing IP filtering from kernel leaves 
everything perfectly stable....  I am attaching dumps, including parsed 
ksyms. Anyone able to help ?

       Thanks, Tom

Kernel panic - not syncing: Caught Machine Check exception - caused by

multiple matching entries in the TLB

ksymoops 2.4.9 on i686 2.6.5-7.151-default.  Options used
     -v ../linux-2.6.11-mipscvs-20050326/vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m ../linux-2.6.11-mipscvs-20050326/System.map (specified)
     -t mipsel -a mipsel

Cpu 0
$ 0   : 00000000 801f0000 c00042a8 000002a8
$ 4   : 801cc6f0 8faf4800 00000080 00000001
$ 8   : 0302a8c0 0102a8c0 8025baf0 8025baf8
$12   : 00ff0000 00000278 0000003e 72756f73
$16   : 00000055 80fd4cac 8025baf0 80fd4d28
$20   : 00000001 00000001 00000000 80f36c00
$24   : 00000008 00426bc0
$28   : 8025a000 8025bac8 8025bc78 801a0d78
Hi    : 00000055
Lo    : 0140d97a
epc   : 801a0f18 ip_nat_setup_info+0x27c/0x59c     Not tainted
Status: 10208403    KERNEL EXL IE
Cause : 00800060
Kernel panic - not syncing: Caught Machine Check exception - caused by
Warning (Oops_read): Code line not seen, dumping what data is available


>>$12; 00ff0000 <__crc_nf_ct_attach+d834e/e919f>
>>$15; 72756f73 <__crc_generic_make_request+1144ec/6a77e7>
>>$17; 80fd4cac <__crc_tcf_exts_destroy+7086d4/72f879>
>>$18; 8025baf0 <__crc_simple_transaction_release+1bada/c6e8a>
>>$19; 80fd4d28 <__crc_tcf_exts_destroy+708750/72f879>
>>$23; 80f36c00 <__crc_tcf_exts_destroy+66a628/72f879>
>>$25; 00426bc0 <__crc_notify_change+2f24b/1fc50f>
>>$28; 8025a000 <__crc_simple_transaction_release+19fea/c6e8a>
>>$29; 8025bac8 <__crc_simple_transaction_release+1bab2/c6e8a>
>>$30; 8025bc78 <__crc_simple_transaction_release+1bc62/c6e8a>
>>$31; 801a0d78 <ip_nat_setup_info+dc/59c>

>>PC;  801a0f18 <ip_nat_setup_info+27c/59c>   <=====

--------------------
Got mcheck at 801a0f18
Cpu 0
$ 0   : 00000000 801f0000 c00042a8 000002a8
$ 4   : 801cc6f0 8faf4800 00000080 00000001
$ 8   : 0302a8c0 0102a8c0 8026fbc8 8026fbd0
$12   : 00ff0000 00000000 00000000 00000000
$16   : 00000055 80270cac 8026fbc8 80270d28
$20   : 00000001 00000001 00000000 80f36c00
$24   : 00000000 0044ffb4
$28   : 8026e000 8026fba0 8026fd50 801a0d78
Hi    : 00000055
Lo    : 0140d97a
epc   : 801a0f18 ip_nat_setup_info+0x27c/0x59c     Not tainted
ra    : 801a0d78 ip_nat_setup_info+0xdc/0x59c
Status: 10208403    KERNEL EXL IE
Cause : 00800060
PrId  : 0001800b

Index:  2 pgmask=4kb va=7fff6000 asid=09
                        [pa=00236000 c=3 d=0 v=0 g=0]
                        [pa=00fdb000 c=3 d=1 v=1 g=0]

Index: 12 pgmask=4kb va=10004000 asid=09
                        [pa=0023d000 c=3 d=1 v=0 g=0]
                        [pa=00fcc000 c=3 d=0 v=0 g=0]

Index: 13 pgmask=4kb va=2ab96000 asid=09
                        [pa=00d86000 c=3 d=0 v=1 g=0]
                        [pa=00000000 c=0 d=0 v=0 g=0]

Index: 14 pgmask=4kb va=00442000 asid=09
                        [pa=00c6f000 c=3 d=0 v=0 g=0]
                        [pa=00c70000 c=3 d=0 v=1 g=0]

Index: 15 pgmask=4kb va=00450000 asid=09
                        [pa=00c7d000 c=3 d=0 v=1 g=0]
                        [pa=00000000 c=0 d=0 v=0 g=0]

Kernel panic - not syncing: Caught Machine Check exception - caused by
multiple matching entries in the TLB.


>>$12; 00ff0000 <__crc_nf_ct_attach+d834e/e919f>
>>$17; 80270cac <__crc_simple_transaction_release+30c96/c6e8a>
>>$18; 8026fbc8 <__crc_simple_transaction_release+2fbb2/c6e8a>
>>$19; 80270d28 <__crc_simple_transaction_release+30d12/c6e8a>
>>$23; 80f36c00 <__crc_tcf_exts_destroy+66a628/72f879>
>>$25; 0044ffb4 <__crc_notify_change+5863f/1fc50f>
>>$28; 8026e000 <__crc_simple_transaction_release+2dfea/c6e8a>
>>$29; 8026fba0 <__crc_simple_transaction_release+2fb8a/c6e8a>
>>$30; 8026fd50 <__crc_simple_transaction_release+2fd3a/c6e8a>
>>$31; 801a0d78 <ip_nat_setup_info+dc/59c>

>>PC;  801a0f18 <ip_nat_setup_info+27c/59c>   <=====

Kernel panic - not syncing: Caught Machine Check exception - caused by



-- 
 Tomas Vrana  <tom@voda.cz>
 --------------------------
 VODA IT consulting, Borkovany 48, 691 75
 http://www.voda.cz/
 phone: +420 519 419 416 mobile: +420 603 469 305 UIN: 105142752






From tom@voda.cz Sat May 28 12:42:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 12:42:58 +0100 (BST)
Received: from gw.voda.cz ([IPv6:::ffff:212.24.154.90]:14254 "EHLO
	smtp.voda.cz") by linux-mips.org with ESMTP id <S8225249AbVE1Lmk>;
	Sat, 28 May 2005 12:42:40 +0100
Received: from localhost (localhost [127.0.0.1])
	by smtp.voda.cz (Postfix) with ESMTP id DCF891DBA9
	for <linux-mips@linux-mips.org>; Sat, 28 May 2005 13:42:38 +0200 (CEST)
Received: from smtp.voda.cz ([127.0.0.1])
 by localhost (gw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 09749-01 for <linux-mips@linux-mips.org>;
 Sat, 28 May 2005 13:42:18 +0200 (CEST)
Received: from [10.1.1.111] (unknown [10.1.1.111])
	by smtp.voda.cz (Postfix) with ESMTP id 0A20A1D802
	for <linux-mips@linux-mips.org>; Sat, 28 May 2005 13:42:12 +0200 (CEST)
Message-ID: <42985913.2040606@voda.cz>
Date:	Sat, 28 May 2005 13:42:11 +0200
From:	=?ISO-8859-2?Q?Tom=E1=B9_Vr=E1na?= <tom@voda.cz>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Cc:	linux-mips@linux-mips.org
Subject: Re: Kernel crash in ip_nat on ADM5120
References: <42984BFC.3000800@voda.cz>
In-Reply-To: <42984BFC.3000800@voda.cz>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at voda.cz
To:	unlisted-recipients:; (no To-header on input)
Return-Path: <tom@voda.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8010
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tom@voda.cz
Precedence: bulk
X-list: linux-mips

Please reply to tom@voda.cz, I posted from wrong profile first.

       Sorry and thanks, Tom

VODA IT wrote:

> Hello,
>
> I get following problem using the 2.6.11 kernel on ADM5120 platform:
> Under heavy network load (ie. flood ping) the kernel crashes in NAT 
> (no nat is done actually), removing IP filtering from kernel leaves 
> everything perfectly stable....  I am attaching dumps, including 
> parsed ksyms. Anyone able to help ?
>
>       Thanks, Tom
>
> Kernel panic - not syncing: Caught Machine Check exception - caused by
>
> multiple matching entries in the TLB
>
> ksymoops 2.4.9 on i686 2.6.5-7.151-default.  Options used
>     -v ../linux-2.6.11-mipscvs-20050326/vmlinux (specified)
>     -K (specified)
>     -L (specified)
>     -O (specified)
>     -m ../linux-2.6.11-mipscvs-20050326/System.map (specified)
>     -t mipsel -a mipsel
>
> Cpu 0
> $ 0   : 00000000 801f0000 c00042a8 000002a8
> $ 4   : 801cc6f0 8faf4800 00000080 00000001
> $ 8   : 0302a8c0 0102a8c0 8025baf0 8025baf8
> $12   : 00ff0000 00000278 0000003e 72756f73
> $16   : 00000055 80fd4cac 8025baf0 80fd4d28
> $20   : 00000001 00000001 00000000 80f36c00
> $24   : 00000008 00426bc0
> $28   : 8025a000 8025bac8 8025bc78 801a0d78
> Hi    : 00000055
> Lo    : 0140d97a
> epc   : 801a0f18 ip_nat_setup_info+0x27c/0x59c     Not tainted
> Status: 10208403    KERNEL EXL IE
> Cause : 00800060
> Kernel panic - not syncing: Caught Machine Check exception - caused by
> Warning (Oops_read): Code line not seen, dumping what data is available
>
>
>>> $12; 00ff0000 <__crc_nf_ct_attach+d834e/e919f>
>>> $15; 72756f73 <__crc_generic_make_request+1144ec/6a77e7>
>>> $17; 80fd4cac <__crc_tcf_exts_destroy+7086d4/72f879>
>>> $18; 8025baf0 <__crc_simple_transaction_release+1bada/c6e8a>
>>> $19; 80fd4d28 <__crc_tcf_exts_destroy+708750/72f879>
>>> $23; 80f36c00 <__crc_tcf_exts_destroy+66a628/72f879>
>>> $25; 00426bc0 <__crc_notify_change+2f24b/1fc50f>
>>> $28; 8025a000 <__crc_simple_transaction_release+19fea/c6e8a>
>>> $29; 8025bac8 <__crc_simple_transaction_release+1bab2/c6e8a>
>>> $30; 8025bc78 <__crc_simple_transaction_release+1bc62/c6e8a>
>>> $31; 801a0d78 <ip_nat_setup_info+dc/59c>
>>
>
>>> PC;  801a0f18 <ip_nat_setup_info+27c/59c>   <=====
>>
>
> --------------------
> Got mcheck at 801a0f18
> Cpu 0
> $ 0   : 00000000 801f0000 c00042a8 000002a8
> $ 4   : 801cc6f0 8faf4800 00000080 00000001
> $ 8   : 0302a8c0 0102a8c0 8026fbc8 8026fbd0
> $12   : 00ff0000 00000000 00000000 00000000
> $16   : 00000055 80270cac 8026fbc8 80270d28
> $20   : 00000001 00000001 00000000 80f36c00
> $24   : 00000000 0044ffb4
> $28   : 8026e000 8026fba0 8026fd50 801a0d78
> Hi    : 00000055
> Lo    : 0140d97a
> epc   : 801a0f18 ip_nat_setup_info+0x27c/0x59c     Not tainted
> ra    : 801a0d78 ip_nat_setup_info+0xdc/0x59c
> Status: 10208403    KERNEL EXL IE
> Cause : 00800060
> PrId  : 0001800b
>
> Index:  2 pgmask=4kb va=7fff6000 asid=09
>                        [pa=00236000 c=3 d=0 v=0 g=0]
>                        [pa=00fdb000 c=3 d=1 v=1 g=0]
>
> Index: 12 pgmask=4kb va=10004000 asid=09
>                        [pa=0023d000 c=3 d=1 v=0 g=0]
>                        [pa=00fcc000 c=3 d=0 v=0 g=0]
>
> Index: 13 pgmask=4kb va=2ab96000 asid=09
>                        [pa=00d86000 c=3 d=0 v=1 g=0]
>                        [pa=00000000 c=0 d=0 v=0 g=0]
>
> Index: 14 pgmask=4kb va=00442000 asid=09
>                        [pa=00c6f000 c=3 d=0 v=0 g=0]
>                        [pa=00c70000 c=3 d=0 v=1 g=0]
>
> Index: 15 pgmask=4kb va=00450000 asid=09
>                        [pa=00c7d000 c=3 d=0 v=1 g=0]
>                        [pa=00000000 c=0 d=0 v=0 g=0]
>
> Kernel panic - not syncing: Caught Machine Check exception - caused by
> multiple matching entries in the TLB.
>
>
>>> $12; 00ff0000 <__crc_nf_ct_attach+d834e/e919f>
>>> $17; 80270cac <__crc_simple_transaction_release+30c96/c6e8a>
>>> $18; 8026fbc8 <__crc_simple_transaction_release+2fbb2/c6e8a>
>>> $19; 80270d28 <__crc_simple_transaction_release+30d12/c6e8a>
>>> $23; 80f36c00 <__crc_tcf_exts_destroy+66a628/72f879>
>>> $25; 0044ffb4 <__crc_notify_change+5863f/1fc50f>
>>> $28; 8026e000 <__crc_simple_transaction_release+2dfea/c6e8a>
>>> $29; 8026fba0 <__crc_simple_transaction_release+2fb8a/c6e8a>
>>> $30; 8026fd50 <__crc_simple_transaction_release+2fd3a/c6e8a>
>>> $31; 801a0d78 <ip_nat_setup_info+dc/59c>
>>
>
>>> PC;  801a0f18 <ip_nat_setup_info+27c/59c>   <=====
>>
>
> Kernel panic - not syncing: Caught Machine Check exception - caused by
>
>
>


-- 
 Tomas Vrana  <tom@voda.cz>
 --------------------------
 VODA IT consulting, Borkovany 48, 691 75
 http://www.voda.cz/
 phone: +420 519 419 416 mobile: +420 603 469 305 UIN: 105142752






From developer@phatlinux.com Sat May 28 16:44:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 16:45:05 +0100 (BST)
Received: from ms-smtp-01-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.135]:41196
	"EHLO ms-smtp-01-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8225297AbVE1Pos>; Sat, 28 May 2005 16:44:48 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-01-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4SFicWY027441;
	Sat, 28 May 2005 11:44:38 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
In-Reply-To: <1117237244.5744.284.camel@localhost.localdomain>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
	 <1117217584.5743.229.camel@localhost.localdomain>
	 <1117223539.2921.15.camel@phatbox>
	 <1117237244.5744.284.camel@localhost.localdomain>
Content-Type: text/plain
Date:	Sat, 28 May 2005 11:43:03 -0400
Message-Id: <1117294983.2800.12.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8011
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

> The 2.6 kernel has uclinux merged but that doesn't include MMUless
> support at the moment. The 2.4 uclinux tree is seperate and Xiptech
> released a set of patches for 2.4.19 for the mmuless mips and for the
> ucLibc if the cpu lacks mipsII and FPU instructions.

It looks like Xiptech only did a port for R3K, which is no good for me.
The issue that I'm running into right now is in
arch/mipsnommu/mm/c-r4k.c

I guess the problem is that it is trying to use things which belong to
the MM code, which are not included from mm.h becuase NO_MM is set.
c-r3k.c was rewritten for NO_MM, but not c-r4k.c. I looked into
rewriting c-r4k.c by taking ideas from c-r3k.c but unfortunatly they are
not similar enough, and I'm afraid I'm not even sure what this file
does. Can you help me understand what this file does, and what I might
do to rewrite it for NO_MM?

Below I've included my compile errors.

Thanks,
Cameron


mipsel-uclibc-gcc -D__KERNEL__
-I/home/cameron/kernel/linux-2.4.19/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-DNO_MM -I /home/cameron/kernel/linux-2.4.19/include/asm/gcc -G 0
-mno-abicalls -fno-pic -pipe -mcpu=r4300 -mips2 -Wa,--trap   -nostdinc
-I /opt/toolchain/lib/gcc-lib/mipsel-linux/3.2/include
-DKBUILD_BASENAME=c_r4k  -c -o c-r4k.o c-r4k.c
c-r4k.c: In function `r4k_flush_cache_range_s16d16i16':
c-r4k.c:130: structure has no member named `context'
c-r4k.c:137: warning: implicit declaration of function `find_vma'
c-r4k.c:137: warning: assignment makes pointer from integer without a
cast
c-r4k.c:139: structure has no member named `context'
c-r4k.c:139: structure has no member named `context'
c-r4k.c:147: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s32d16i16':
c-r4k.c:166: structure has no member named `context'
c-r4k.c:173: warning: assignment makes pointer from integer without a
cast
c-r4k.c:175: structure has no member named `context'
c-r4k.c:175: structure has no member named `context'
c-r4k.c:183: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s64d16i16':
c-r4k.c:201: structure has no member named `context'
c-r4k.c:208: warning: assignment makes pointer from integer without a
cast
c-r4k.c:210: structure has no member named `context'
c-r4k.c:210: structure has no member named `context'
c-r4k.c:218: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s128d16i16':
c-r4k.c:236: structure has no member named `context'
c-r4k.c:243: warning: assignment makes pointer from integer without a
cast
c-r4k.c:245: structure has no member named `context'
c-r4k.c:245: structure has no member named `context'
c-r4k.c:253: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s32d32i32':
c-r4k.c:271: structure has no member named `context'
c-r4k.c:278: warning: assignment makes pointer from integer without a
cast
c-r4k.c:280: structure has no member named `context'
c-r4k.c:280: structure has no member named `context'
c-r4k.c:288: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s64d32i32':
c-r4k.c:306: structure has no member named `context'
c-r4k.c:313: warning: assignment makes pointer from integer without a
cast
c-r4k.c:315: structure has no member named `context'
c-r4k.c:315: structure has no member named `context'
c-r4k.c:323: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s128d32i32':
c-r4k.c:341: structure has no member named `context'
c-r4k.c:348: warning: assignment makes pointer from integer without a
cast
c-r4k.c:350: structure has no member named `context'
c-r4k.c:350: structure has no member named `context'
c-r4k.c:358: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_d16i16':
c-r4k.c:374: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_range_d32i32':
c-r4k.c:386: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s16d16i16':
c-r4k.c:401: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s32d16i16':
c-r4k.c:411: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s64d16i16':
c-r4k.c:421: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s128d16i16':
c-r4k.c:431: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s32d32i32':
c-r4k.c:441: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s64d32i32':
c-r4k.c:451: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s128d32i32':
c-r4k.c:461: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_d16i16':
c-r4k.c:471: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_d32i32':
c-r4k.c:481: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_page_s16d16i16':
c-r4k.c:492: structure has no member named `vm_mm'
c-r4k.c:501: structure has no member named `context'
c-r4k.c:508: warning: assignment makes pointer from integer without a
cast
c-r4k.c:525: structure has no member named `context'
c-r4k.c:525: structure has no member named `context'
c-r4k.c:536: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s32d16i16':
c-r4k.c:541: structure has no member named `vm_mm'
c-r4k.c:550: structure has no member named `context'
c-r4k.c:557: warning: assignment makes pointer from integer without a
cast
c-r4k.c:573: structure has no member named `context'
c-r4k.c:573: structure has no member named `context'
c-r4k.c:584: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s64d16i16':
c-r4k.c:589: structure has no member named `vm_mm'
c-r4k.c:598: structure has no member named `context'
c-r4k.c:605: warning: assignment makes pointer from integer without a
cast
c-r4k.c:621: structure has no member named `context'
c-r4k.c:621: structure has no member named `context'
c-r4k.c:632: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s128d16i16':
c-r4k.c:637: structure has no member named `vm_mm'
c-r4k.c:646: structure has no member named `context'
c-r4k.c:653: warning: assignment makes pointer from integer without a
cast
c-r4k.c:670: structure has no member named `context'
c-r4k.c:670: structure has no member named `context'
c-r4k.c:681: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s32d32i32':
c-r4k.c:686: structure has no member named `vm_mm'
c-r4k.c:695: structure has no member named `context'
c-r4k.c:702: warning: assignment makes pointer from integer without a
cast
c-r4k.c:719: structure has no member named `context'
c-r4k.c:719: structure has no member named `context'
c-r4k.c:730: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s64d32i32':
c-r4k.c:735: structure has no member named `vm_mm'
c-r4k.c:744: structure has no member named `context'
c-r4k.c:751: warning: assignment makes pointer from integer without a
cast
c-r4k.c:768: structure has no member named `context'
c-r4k.c:768: structure has no member named `context'
c-r4k.c:779: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s128d32i32':
c-r4k.c:784: structure has no member named `vm_mm'
c-r4k.c:793: structure has no member named `context'
c-r4k.c:800: warning: assignment makes pointer from integer without a
cast
c-r4k.c:817: structure has no member named `context'
c-r4k.c:817: structure has no member named `context'
c-r4k.c:827: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_d16i16':
c-r4k.c:832: structure has no member named `vm_mm'
c-r4k.c:841: structure has no member named `context'
c-r4k.c:848: warning: assignment makes pointer from integer without a
cast
c-r4k.c:875: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_d32i32':
c-r4k.c:880: structure has no member named `vm_mm'
c-r4k.c:889: structure has no member named `context'
c-r4k.c:896: warning: assignment makes pointer from integer without a
cast
c-r4k.c:924: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_d32i32_r4600':
c-r4k.c:929: structure has no member named `vm_mm'
c-r4k.c:938: structure has no member named `context'
c-r4k.c:945: warning: assignment makes pointer from integer without a
cast
c-r4k.c:973: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `setup_noscache_funcs':
c-r4k.c:1360: `_dma_cache_wback_inv' undeclared (first use in this
function)
c-r4k.c:1360: (Each undeclared identifier is reported only once
c-r4k.c:1360: for each function it appears in.)
c-r4k.c:1361: `_dma_cache_wback' undeclared (first use in this function)
c-r4k.c:1362: `_dma_cache_inv' undeclared (first use in this function)
c-r4k.c: In function `setup_scache_funcs':
c-r4k.c:1443: `_dma_cache_wback_inv' undeclared (first use in this
function)
c-r4k.c:1444: `_dma_cache_wback' undeclared (first use in this function)
c-r4k.c:1445: `_dma_cache_inv' undeclared (first use in this function)
make[2]: *** [c-r4k.o] Error 1
make[2]: Leaving directory
`/home/cameron/kernel/linux-2.4.19/arch/mipsnommu/mm'make[1]: ***
[first_rule] Error 2
make[1]: Leaving directory
`/home/cameron/kernel/linux-2.4.19/arch/mipsnommu/mm'make: ***
[_dir_arch/mipsnommu/mm] Error 2




From developer@phatlinux.com Sat May 28 16:49:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 16:50:14 +0100 (BST)
Received: from ms-smtp-04-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.138]:11496
	"EHLO ms-smtp-04-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8225305AbVE1Pt7>; Sat, 28 May 2005 16:49:59 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-04-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4SFnaHH026390;
	Sat, 28 May 2005 11:49:37 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.10.10505280852210.25329-100000@helios.et.put.poznan.pl>
References: <Pine.GSO.4.10.10505280852210.25329-100000@helios.et.put.poznan.pl>
Content-Type: text/plain
Date:	Sat, 28 May 2005 11:48:01 -0400
Message-Id: <1117295281.2800.17.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8012
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

> PS. Besides, does taking one apart actually impart any knowledge? I looked
> at the photos, if that helps ;)

A number of people have taken PSPs apart. The only useful thing that has
come from it was a dump of the firmware. Now that we have that it
doesn't seem that there is much else to do since we don't know anything
about the chips and there are not too many visible traces. However, if
you have a new idea of something that could be done to the hardware,
then maybe there would be a reason to sacrifice another.

Cameron



From ralf@linux-mips.org Sat May 28 20:28:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:28:34 +0100 (BST)
Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:61887 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225363AbVE1T2T>; Sat, 28 May 2005 20:28:19 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4SJR62h008048;
	Sat, 28 May 2005 20:27:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4SJR4qo008047;
	Sat, 28 May 2005 20:27:04 +0100
Date:	Sat, 28 May 2005 20:27:04 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Cameron Cooper <developer@phatlinux.com>
Cc:	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
Subject: Re: Porting To New System
Message-ID: <20050528192704.GA4995@linux-mips.org>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl> <1117217584.5743.229.camel@localhost.localdomain> <1117223539.2921.15.camel@phatbox> <1117237244.5744.284.camel@localhost.localdomain> <1117294983.2800.12.camel@phatbox>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1117294983.2800.12.camel@phatbox>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8013
X-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 Sat, May 28, 2005 at 11:43:03AM -0400, Cameron Cooper wrote:

> It looks like Xiptech only did a port for R3K, which is no good for me.
> The issue that I'm running into right now is in
> arch/mipsnommu/mm/c-r4k.c

Sort of amusing to make that a separate architecture - TLB or not, the
remainder of the CPU stays pretty much the same.

> I guess the problem is that it is trying to use things which belong to
> the MM code, which are not included from mm.h becuase NO_MM is set.
> c-r3k.c was rewritten for NO_MM, but not c-r4k.c. I looked into
> rewriting c-r4k.c by taking ideas from c-r3k.c but unfortunatly they are
> not similar enough, and I'm afraid I'm not even sure what this file
> does.

The key feature of R4000 caches that causes alot of complexity in the
c-r4k code is that it needs to handle virtually indexed caches, especially
avoid cache aliases.  On a TLB-less processors aliases are not possible,
thus c-r4k.c can be significantly simplified making it quite a bit more
similar to c-r3k.c.

> Can you help me understand what this file does, and what I might
> do to rewrite it for NO_MM?

Your question would require a very long answer to be somewhat exhaustive,
so here the express version.  Start by reading Documentation/cachetlb.txt
from the kernel sources.  You can find plenty of discussions related to
this code in the linux-mips and linux-kernel archives - especially the
subtle points aren't exactly documented ;-)

  Ralf

From developer@phatlinux.com Sat May 28 20:37:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:37:46 +0100 (BST)
Received: from ms-smtp-04-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.138]:19596
	"EHLO ms-smtp-04-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8225377AbVE1Thb>; Sat, 28 May 2005 20:37:31 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-04-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4SJbPHH005341;
	Sat, 28 May 2005 15:37:25 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	linux-mips@linux-mips.org
In-Reply-To: <20050528192704.GA4995@linux-mips.org>
References: <Pine.GSO.4.10.10505271929510.25076-100000@helios.et.put.poznan.pl>
	 <1117217584.5743.229.camel@localhost.localdomain>
	 <1117223539.2921.15.camel@phatbox>
	 <1117237244.5744.284.camel@localhost.localdomain>
	 <1117294983.2800.12.camel@phatbox>  <20050528192704.GA4995@linux-mips.org>
Content-Type: text/plain
Date:	Sat, 28 May 2005 15:35:50 -0400
Message-Id: <1117308950.2800.51.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8014
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

> Your question would require a very long answer to be somewhat exhaustive,
> so here the express version.  Start by reading Documentation/cachetlb.txt
> from the kernel sources.  You can find plenty of discussions related to
> this code in the linux-mips and linux-kernel archives - especially the
> subtle points aren't exactly documented ;-)

Thanks, I'll check that out. However a new complexity has arisen. It
turns out that in addition to not having access to the MMU, we do not
have access to cp0. I'm afraid that this would require even more
rewriting of the kernel. Although I started this to learn something,
there might be more involved in this than I am prepared for.

Cameron


From ralf@linux-mips.org Sat May 28 20:39:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:39:53 +0100 (BST)
Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:56507 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225377AbVE1Tji>; Sat, 28 May 2005 20:39:38 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4SJcSGN008515;
	Sat, 28 May 2005 20:38:29 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4RMpfrK005460;
	Fri, 27 May 2005 23:51:41 +0100
Date:	Fri, 27 May 2005 23:51:41 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	developer <developer@phatlinux.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
Message-ID: <20050527225141.GA4575@linux-mips.org>
References: <20050527031123.1327.qmail@server256.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050527031123.1327.qmail@server256.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8015
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, May 27, 2005 at 03:11:23AM +0000, developer wrote:

> I'm a long time Linux user, and computer engineering student. I've recently become interested in porting Linux to Sony's PSP gaming system. I'm wanting to do this mainly as an exercise in understanding the kernel better, also I just think it would be neat :). The PSP system has a MIPS R4000 CPU which is already supported

Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.

  Ralf

From developer@phatlinux.com Sat May 28 20:45:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:45:38 +0100 (BST)
Received: from ms-smtp-04-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.138]:664
	"EHLO ms-smtp-04-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8225377AbVE1TpY>; Sat, 28 May 2005 20:45:24 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-04-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4SJjJHH009527;
	Sat, 28 May 2005 15:45:20 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050527225141.GA4575@linux-mips.org>
References: <20050527031123.1327.qmail@server256.com>
	 <20050527225141.GA4575@linux-mips.org>
Content-Type: text/plain
Date:	Sat, 28 May 2005 15:43:44 -0400
Message-Id: <1117309424.2800.54.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8016
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

> Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.

It's a R4000.

http://www.linux-mips.org/wiki/index.php/PSP

Cameron


From ths@networkno.de Sat May 28 20:50:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:50:35 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:13231 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8225377AbVE1TuV>;
	Sat, 28 May 2005 20:50:21 +0100
Received: from port-195-158-167-89.dynamic.qsc.de ([195.158.167.89] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1Dc7Jz-0007nZ-00; Sat, 28 May 2005 21:50:11 +0200
Received: from ths by hattusa.textio with local (Exim 4.50)
	id 1Dc7Jz-0005Pw-9X; Sat, 28 May 2005 21:50:11 +0200
Date:	Sat, 28 May 2005 21:50:11 +0200
To:	Cameron Cooper <developer@phatlinux.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
Message-ID: <20050528195011.GE16649@hattusa.textio>
References: <20050527031123.1327.qmail@server256.com> <20050527225141.GA4575@linux-mips.org> <1117309424.2800.54.camel@phatbox>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1117309424.2800.54.camel@phatbox>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8017
X-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

Cameron Cooper wrote:
> > Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.
> 
> It's a R4000.
> 
> http://www.linux-mips.org/wiki/index.php/PSP

That's what the press release claims, but it is most likely wrong.


Thiemo

From ralf@linux-mips.org Sat May 28 20:56:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:56:30 +0100 (BST)
Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:42153 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225406AbVE1T4P>; Sat, 28 May 2005 20:56:15 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j4SJt5v8010353;
	Sat, 28 May 2005 20:55:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j4SJt56J010352;
	Sat, 28 May 2005 20:55:05 +0100
Date:	Sat, 28 May 2005 20:55:03 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Cameron Cooper <developer@phatlinux.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Porting To New System
Message-ID: <20050528195503.GB4995@linux-mips.org>
References: <20050527031123.1327.qmail@server256.com> <20050527225141.GA4575@linux-mips.org> <1117309424.2800.54.camel@phatbox>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1117309424.2800.54.camel@phatbox>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8018
X-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 Sat, May 28, 2005 at 03:43:44PM -0400, Cameron Cooper wrote:

> > Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.
> 
> It's a R4000.
> 
> http://www.linux-mips.org/wiki/index.php/PSP

Don't believe everything you read ...  Sony claims the processors are two
R4000 32-bit cores.  Which is obvious nonsense, the R4000 is 64-bit.

  Ralf

From developer@phatlinux.com Sat May 28 20:57:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 May 2005 20:57:40 +0100 (BST)
Received: from ms-smtp-01-smtplb.ohiordc.rr.com ([IPv6:::ffff:65.24.5.135]:58540
	"EHLO ms-smtp-01-eri0.ohiordc.rr.com") by linux-mips.org with ESMTP
	id <S8225406AbVE1T5Z>; Sat, 28 May 2005 20:57:25 +0100
Received: from [192.168.0.3] (cpe-65-24-168-255.columbus.res.rr.com [65.24.168.255])
	by ms-smtp-01-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j4SJvKWY012312;
	Sat, 28 May 2005 15:57:21 -0400 (EDT)
Subject: Re: Porting To New System
From:	Cameron Cooper <developer@phatlinux.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050528195503.GB4995@linux-mips.org>
References: <20050527031123.1327.qmail@server256.com>
	 <20050527225141.GA4575@linux-mips.org> <1117309424.2800.54.camel@phatbox>
	 <20050528195503.GB4995@linux-mips.org>
Content-Type: text/plain
Date:	Sat, 28 May 2005 15:55:43 -0400
Message-Id: <1117310143.2800.65.camel@phatbox>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
Return-Path: <developer@phatlinux.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8019
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: developer@phatlinux.com
Precedence: bulk
X-list: linux-mips

> Don't believe everything you read ...  Sony claims the processors are two
> R4000 32-bit cores.  Which is obvious nonsense, the R4000 is 64-bit.

Thanks, that is very useful to know.

Cameron


From yuasa@hh.iij4u.or.jp Sun May 29 16:06:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 May 2005 16:06:24 +0100 (BST)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:33535 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224812AbVE2PGE>;
	Sun, 29 May 2005 16:06:04 +0100
Received: MO(mo00)id j4TF5wTi005845; Mon, 30 May 2005 00:05:58 +0900 (JST)
Received: MDO(mdo01) id j4TF5vk1011099; Mon, 30 May 2005 00:05:57 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j4TF5uaW007910
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Mon, 30 May 2005 00:05:57 +0900 (JST)
Date:	Mon, 30 May 2005 00:05:46 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: update IRQ handling
Message-Id: <20050530000546.5b7da65d.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8020
X-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,

This patch had updated IRQ handling for vr41xx.
o added common IRQ dispatch
o changed IRQ number in int-handler.S
o added resource management to icu.c

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/Makefile a/arch/mips/vr41xx/common/Makefile
--- a-orig/arch/mips/vr41xx/common/Makefile	Fri May 20 07:27:41 2005
+++ a/arch/mips/vr41xx/common/Makefile	Sat May 28 18:30:33 2005
@@ -2,7 +2,7 @@
 # Makefile for common code of the NEC VR4100 series.
 #
 
-obj-y				+= bcu.o cmu.o icu.o init.o int-handler.o pmu.o
+obj-y				+= bcu.o cmu.o icu.o init.o int-handler.o irq.o pmu.o
 obj-$(CONFIG_GPIO_VR41XX)	+= giu.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
 
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/giu.c a/arch/mips/vr41xx/common/giu.c
--- a-orig/arch/mips/vr41xx/common/giu.c	Fri Apr 15 00:14:15 2005
+++ a/arch/mips/vr41xx/common/giu.c	Sat May 28 19:03:27 2005
@@ -291,60 +291,7 @@
 
 EXPORT_SYMBOL(vr41xx_set_irq_level);
 
-#ifndef MODULE
-
-#define GIUINT_NR_IRQS		32
-
-enum {
-	GIUINT_NO_CASCADE,
-	GIUINT_CASCADE
-};
-
-struct vr41xx_giuint_cascade {
-	unsigned int flag;
-	int (*get_irq_number)(int irq);
-};
-
-static struct vr41xx_giuint_cascade giuint_cascade[GIUINT_NR_IRQS];
-
-static struct irqaction giu_cascade = {
-	.handler	= no_action,
-	.mask		= CPU_MASK_NONE,
-	.name		= "cascade",
-};
-
-static int no_irq_number(int irq)
-{
-	return -EINVAL;
-}
-
-int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq))
-{
-	unsigned int pin;
-	int retval;
-
-	if (irq < GIU_IRQ(0) || irq > GIU_IRQ(31))
-		return -EINVAL;
-
-	if(!get_irq_number)
-		return -EINVAL;
-
-	pin = GIU_IRQ_TO_PIN(irq);
-	giuint_cascade[pin].flag = GIUINT_CASCADE;
-	giuint_cascade[pin].get_irq_number = get_irq_number;
-
-	retval = setup_irq(irq, &giu_cascade);
-	if (retval != 0) {
-		giuint_cascade[pin].flag = GIUINT_NO_CASCADE;
-		giuint_cascade[pin].get_irq_number = no_irq_number;
-	}
-
-	return retval;
-}
-
-EXPORT_SYMBOL(vr41xx_cascade_irq);
-
-static inline int get_irq_pin_number(void)
+static int giu_get_irq(unsigned int irq, struct pt_regs *regs)
 {
 	uint16_t pendl, pendh, maskl, maskh;
 	int i;
@@ -360,12 +307,12 @@
 	if (maskl) {
 		for (i = 0; i < 16; i++) {
 			if (maskl & ((uint16_t)1 << i))
-				return i;
+				return GIU_IRQ(i);
 		}
 	} else if (maskh) {
 		for (i = 0; i < 16; i++) {
 			if (maskh & ((uint16_t)1 << i))
-				return i + GIUINT_HIGH_OFFSET;
+				return GIU_IRQ(i + GIUINT_HIGH_OFFSET);
 		}
 	}
 
@@ -377,54 +324,7 @@
 	return -1;
 }
 
-static inline void ack_giuint_irq(int pin)
-{
-	if (pin < GIUINT_HIGH_OFFSET) {
-		clear_giuint(GIUINTENL, (uint16_t)1 << pin);
-		write_giuint((uint16_t)1 << pin, GIUINTSTATL);
-	} else {
-		pin -= GIUINT_HIGH_OFFSET;
-		clear_giuint(GIUINTENH, (uint16_t)1 << pin);
-		write_giuint((uint16_t)1 << pin, GIUINTSTATH);
-	}
-}
-
-static inline void end_giuint_irq(int pin)
-{
-	if (pin < GIUINT_HIGH_OFFSET)
-		set_giuint(GIUINTENL, (uint16_t)1 << pin);
-	else
-		set_giuint(GIUINTENH, (uint16_t)1 << (pin - GIUINT_HIGH_OFFSET));
-}
-
-void giuint_irq_dispatch(struct pt_regs *regs)
-{
-	struct vr41xx_giuint_cascade *cascade;
-	unsigned int giuint_irq;
-	int pin;
-
-	pin = get_irq_pin_number();
-	if (pin < 0)
-		return;
-
-	disable_irq(GIUINT_CASCADE_IRQ);
-
-	cascade = &giuint_cascade[pin];
-	giuint_irq = GIU_IRQ(pin);
-	if (cascade->flag == GIUINT_CASCADE) {
-		int irq = cascade->get_irq_number(giuint_irq);
-		ack_giuint_irq(pin);
-		if (irq >= 0)
-			do_IRQ(irq, regs);
-		end_giuint_irq(pin);
-	} else {
-		do_IRQ(giuint_irq, regs);
-	}
-
-	enable_irq(GIUINT_CASCADE_IRQ);
-}
-
-void __init init_vr41xx_giuint_irq(void)
+static int  __init vr41xx_giu_init(void)
 {
 	int i;
 
@@ -440,16 +340,14 @@
 		break;
 	default:
 		printk(KERN_ERR "GIU: Unexpected CPU of NEC VR4100 series\n");
-		return;
+		return -ENODEV;
 	}
 
-	for (i = 0; i < GIUINT_NR_IRQS; i++) {
+	for (i = 0; i < 32; i++) {
 		if (i < GIUINT_HIGH_OFFSET)
 			clear_giuint(GIUINTENL, (uint16_t)1 << i);
 		else
 			clear_giuint(GIUINTENH, (uint16_t)1 << (i - GIUINT_HIGH_OFFSET));
-		giuint_cascade[i].flag = GIUINT_NO_CASCADE;
-		giuint_cascade[i].get_irq_number = no_irq_number;
 	}
 
 	for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) {
@@ -459,7 +357,7 @@
 			irq_desc[i].handler = &giuint_high_irq_type;
 	}
 
-	setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade);
+	return cascade_irq(GIUINT_IRQ, giu_get_irq);
 }
 
-#endif
+postcore_initcall(vr41xx_giu_init);
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/icu.c a/arch/mips/vr41xx/common/icu.c
--- a-orig/arch/mips/vr41xx/common/icu.c	Tue Mar  8 08:10:16 2005
+++ a/arch/mips/vr41xx/common/icu.c	Sat May 28 18:29:11 2005
@@ -28,10 +28,10 @@
  *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *  - Coped with INTASSIGN of NEC VR4133.
  */
-#include <linux/config.h>
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/ioport.h>
 #include <linux/irq.h>
 #include <linux/module.h>
 #include <linux/smp.h>
@@ -43,32 +43,22 @@
 #include <asm/irq_cpu.h>
 #include <asm/vr41xx/vr41xx.h>
 
-extern asmlinkage void vr41xx_handle_interrupt(void);
-
-#ifdef CONFIG_GPIO_VR41XX
-extern void init_vr41xx_giuint_irq(void);
-extern void giuint_irq_dispatch(struct pt_regs *regs);
-#endif
-
-static uint32_t icu1_base;
-static uint32_t icu2_base;
-
-static struct irqaction icu_cascade = {
-	.handler	= no_action,
-	.mask		= CPU_MASK_NONE,
-	.name		= "cascade",
-};
+static void __iomem *icu1_base;
+static void __iomem *icu2_base;
 
 static unsigned char sysint1_assign[16] = {
 	0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
 static unsigned char sysint2_assign[16] = {
-	2, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+	2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+
+#define ICU1_TYPE1_BASE	0x0b000080UL
+#define ICU2_TYPE1_BASE	0x0b000200UL
 
-#define SYSINT1REG_TYPE1	KSEG1ADDR(0x0b000080)
-#define SYSINT2REG_TYPE1	KSEG1ADDR(0x0b000200)
+#define ICU1_TYPE2_BASE	0x0f000080UL
+#define ICU2_TYPE2_BASE	0x0f0000a0UL
 
-#define SYSINT1REG_TYPE2	KSEG1ADDR(0x0f000080)
-#define SYSINT2REG_TYPE2	KSEG1ADDR(0x0f0000a0)
+#define ICU1_SIZE	0x20
+#define ICU2_SIZE	0x1c
 
 #define SYSINT1REG	0x00
 #define PIUINTREG	0x02
@@ -108,61 +98,61 @@
 #define SYSINT1_IRQ_TO_PIN(x)	((x) - SYSINT1_IRQ_BASE)	/* Pin 0-15 */
 #define SYSINT2_IRQ_TO_PIN(x)	((x) - SYSINT2_IRQ_BASE)	/* Pin 0-15 */
 
-#define read_icu1(offset)	readw(icu1_base + (offset))
-#define write_icu1(val, offset)	writew((val), icu1_base + (offset))
+#define INT_TO_IRQ(x)		((x) + 2)	/* Int0-4 -> IRQ2-6 */
 
-#define read_icu2(offset)	readw(icu2_base + (offset))
-#define write_icu2(val, offset)	writew((val), icu2_base + (offset))
+#define icu1_read(offset)		readw(icu1_base + (offset))
+#define icu1_write(offset, value)	writew((value), icu1_base + (offset))
+
+#define icu2_read(offset)		readw(icu2_base + (offset))
+#define icu2_write(offset, value)	writew((value), icu2_base + (offset))
 
 #define INTASSIGN_MAX	4
 #define INTASSIGN_MASK	0x0007
 
-static inline uint16_t set_icu1(uint8_t offset, uint16_t set)
+static inline uint16_t icu1_set(uint8_t offset, uint16_t set)
 {
-	uint16_t res;
+	uint16_t data;
 
-	res = read_icu1(offset);
-	res |= set;
-	write_icu1(res, offset);
+	data = icu1_read(offset);
+	data |= set;
+	icu1_write(offset, data);
 
-	return res;
+	return data;
 }
 
-static inline uint16_t clear_icu1(uint8_t offset, uint16_t clear)
+static inline uint16_t icu1_clear(uint8_t offset, uint16_t clear)
 {
-	uint16_t res;
+	uint16_t data;
 
-	res = read_icu1(offset);
-	res &= ~clear;
-	write_icu1(res, offset);
+	data = icu1_read(offset);
+	data &= ~clear;
+	icu1_write(offset, data);
 
-	return res;
+	return data;
 }
 
-static inline uint16_t set_icu2(uint8_t offset, uint16_t set)
+static inline uint16_t icu2_set(uint8_t offset, uint16_t set)
 {
-	uint16_t res;
+	uint16_t data;
 
-	res = read_icu2(offset);
-	res |= set;
-	write_icu2(res, offset);
+	data = icu2_read(offset);
+	data |= set;
+	icu2_write(offset, data);
 
-	return res;
+	return data;
 }
 
-static inline uint16_t clear_icu2(uint8_t offset, uint16_t clear)
+static inline uint16_t icu2_clear(uint8_t offset, uint16_t clear)
 {
-	uint16_t res;
+	uint16_t data;
 
-	res = read_icu2(offset);
-	res &= ~clear;
-	write_icu2(res, offset);
+	data = icu2_read(offset);
+	data &= ~clear;
+	icu2_write(offset, data);
 
-	return res;
+	return data;
 }
 
-/*=======================================================================*/
-
 void vr41xx_enable_piuint(uint16_t mask)
 {
 	irq_desc_t *desc = irq_desc + PIU_IRQ;
@@ -171,7 +161,7 @@
 	if (current_cpu_data.cputype == CPU_VR4111 ||
 	    current_cpu_data.cputype == CPU_VR4121) {
 		spin_lock_irqsave(&desc->lock, flags);
-		set_icu1(MPIUINTREG, mask);
+		icu1_set(MPIUINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -186,7 +176,7 @@
 	if (current_cpu_data.cputype == CPU_VR4111 ||
 	    current_cpu_data.cputype == CPU_VR4121) {
 		spin_lock_irqsave(&desc->lock, flags);
-		clear_icu1(MPIUINTREG, mask);
+		icu1_clear(MPIUINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -201,7 +191,7 @@
 	if (current_cpu_data.cputype == CPU_VR4111 ||
 	    current_cpu_data.cputype == CPU_VR4121) {
 		spin_lock_irqsave(&desc->lock, flags);
-		set_icu1(MAIUINTREG, mask);
+		icu1_set(MAIUINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -216,7 +206,7 @@
 	if (current_cpu_data.cputype == CPU_VR4111 ||
 	    current_cpu_data.cputype == CPU_VR4121) {
 		spin_lock_irqsave(&desc->lock, flags);
-		clear_icu1(MAIUINTREG, mask);
+		icu1_clear(MAIUINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -231,7 +221,7 @@
 	if (current_cpu_data.cputype == CPU_VR4111 ||
 	    current_cpu_data.cputype == CPU_VR4121) {
 		spin_lock_irqsave(&desc->lock, flags);
-		set_icu1(MKIUINTREG, mask);
+		icu1_set(MKIUINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -246,7 +236,7 @@
 	if (current_cpu_data.cputype == CPU_VR4111 ||
 	    current_cpu_data.cputype == CPU_VR4121) {
 		spin_lock_irqsave(&desc->lock, flags);
-		clear_icu1(MKIUINTREG, mask);
+		icu1_clear(MKIUINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -259,7 +249,7 @@
 	unsigned long flags;
 
 	spin_lock_irqsave(&desc->lock, flags);
-	set_icu1(MDSIUINTREG, mask);
+	icu1_set(MDSIUINTREG, mask);
 	spin_unlock_irqrestore(&desc->lock, flags);
 }
 
@@ -271,7 +261,7 @@
 	unsigned long flags;
 
 	spin_lock_irqsave(&desc->lock, flags);
-	clear_icu1(MDSIUINTREG, mask);
+	icu1_clear(MDSIUINTREG, mask);
 	spin_unlock_irqrestore(&desc->lock, flags);
 }
 
@@ -283,7 +273,7 @@
 	unsigned long flags;
 
 	spin_lock_irqsave(&desc->lock, flags);
-	set_icu2(MFIRINTREG, mask);
+	icu2_set(MFIRINTREG, mask);
 	spin_unlock_irqrestore(&desc->lock, flags);
 }
 
@@ -295,7 +285,7 @@
 	unsigned long flags;
 
 	spin_lock_irqsave(&desc->lock, flags);
-	clear_icu2(MFIRINTREG, mask);
+	icu2_clear(MFIRINTREG, mask);
 	spin_unlock_irqrestore(&desc->lock, flags);
 }
 
@@ -310,7 +300,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		write_icu2(PCIINT0, MPCIINTREG);
+		icu2_write(MPCIINTREG, PCIINT0);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -326,7 +316,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		write_icu2(0, MPCIINTREG);
+		icu2_write(MPCIINTREG, 0);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -342,7 +332,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		write_icu2(SCUINT0, MSCUINTREG);
+		icu2_write(MSCUINTREG, SCUINT0);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -358,7 +348,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		write_icu2(0, MSCUINTREG);
+		icu2_write(MSCUINTREG, 0);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -374,7 +364,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		set_icu2(MCSIINTREG, mask);
+		icu2_set(MCSIINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -390,7 +380,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		clear_icu2(MCSIINTREG, mask);
+		icu2_clear(MCSIINTREG, mask);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -406,7 +396,7 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		write_icu2(BCUINTR, MBCUINTREG);
+		icu2_write(MBCUINTREG, BCUINTR);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
@@ -422,30 +412,28 @@
 	    current_cpu_data.cputype == CPU_VR4131 ||
 	    current_cpu_data.cputype == CPU_VR4133) {
 		spin_lock_irqsave(&desc->lock, flags);
-		write_icu2(0, MBCUINTREG);
+		icu2_write(MBCUINTREG, 0);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
 
 EXPORT_SYMBOL(vr41xx_disable_bcuint);
 
-/*=======================================================================*/
-
 static unsigned int startup_sysint1_irq(unsigned int irq)
 {
-	set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq));
+	icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq));
 
 	return 0; /* never anything pending */
 }
 
 static void shutdown_sysint1_irq(unsigned int irq)
 {
-	clear_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq));
+	icu1_clear(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq));
 }
 
 static void enable_sysint1_irq(unsigned int irq)
 {
-	set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq));
+	icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq));
 }
 
 #define disable_sysint1_irq	shutdown_sysint1_irq
@@ -454,7 +442,7 @@
 static void end_sysint1_irq(unsigned int irq)
 {
 	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-		set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq));
+		icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq));
 }
 
 static struct hw_interrupt_type sysint1_irq_type = {
@@ -467,23 +455,21 @@
 	.end		= end_sysint1_irq,
 };
 
-/*=======================================================================*/
-
 static unsigned int startup_sysint2_irq(unsigned int irq)
 {
-	set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq));
+	icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq));
 
 	return 0; /* never anything pending */
 }
 
 static void shutdown_sysint2_irq(unsigned int irq)
 {
-	clear_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq));
+	icu2_clear(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq));
 }
 
 static void enable_sysint2_irq(unsigned int irq)
 {
-	set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq));
+	icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq));
 }
 
 #define disable_sysint2_irq	shutdown_sysint2_irq
@@ -492,7 +478,7 @@
 static void end_sysint2_irq(unsigned int irq)
 {
 	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-		set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq));
+		icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq));
 }
 
 static struct hw_interrupt_type sysint2_irq_type = {
@@ -505,8 +491,6 @@
 	.end		= end_sysint2_irq,
 };
 
-/*=======================================================================*/
-
 static inline int set_sysint1_assign(unsigned int irq, unsigned char assign)
 {
 	irq_desc_t *desc = irq_desc + irq;
@@ -517,8 +501,8 @@
 
 	spin_lock_irq(&desc->lock);
 
-	intassign0 = read_icu1(INTASSIGN0);
-	intassign1 = read_icu1(INTASSIGN1);
+	intassign0 = icu1_read(INTASSIGN0);
+	intassign1 = icu1_read(INTASSIGN1);
 
 	switch (pin) {
 	case 0:
@@ -558,8 +542,8 @@
 	}
 
 	sysint1_assign[pin] = assign;
-	write_icu1(intassign0, INTASSIGN0);
-	write_icu1(intassign1, INTASSIGN1);
+	icu1_write(INTASSIGN0, intassign0);
+	icu1_write(INTASSIGN1, intassign1);
 
 	spin_unlock_irq(&desc->lock);
 
@@ -576,8 +560,8 @@
 
 	spin_lock_irq(&desc->lock);
 
-	intassign2 = read_icu1(INTASSIGN2);
-	intassign3 = read_icu1(INTASSIGN3);
+	intassign2 = icu1_read(INTASSIGN2);
+	intassign3 = icu1_read(INTASSIGN3);
 
 	switch (pin) {
 	case 0:
@@ -625,8 +609,8 @@
 	}
 
 	sysint2_assign[pin] = assign;
-	write_icu1(intassign2, INTASSIGN2);
-	write_icu1(intassign3, INTASSIGN3);
+	icu1_write(INTASSIGN2, intassign2);
+	icu1_write(INTASSIGN3, intassign3);
 
 	spin_unlock_irq(&desc->lock);
 
@@ -653,81 +637,92 @@
 
 EXPORT_SYMBOL(vr41xx_set_intassign);
 
-/*=======================================================================*/
-
-asmlinkage void irq_dispatch(unsigned char intnum, struct pt_regs *regs)
+static int icu_get_irq(unsigned int irq, struct pt_regs *regs)
 {
 	uint16_t pend1, pend2;
 	uint16_t mask1, mask2;
 	int i;
 
-	pend1 = read_icu1(SYSINT1REG);
-	mask1 = read_icu1(MSYSINT1REG);
+	pend1 = icu1_read(SYSINT1REG);
+	mask1 = icu1_read(MSYSINT1REG);
 
-	pend2 = read_icu2(SYSINT2REG);
-	mask2 = read_icu2(MSYSINT2REG);
+	pend2 = icu2_read(SYSINT2REG);
+	mask2 = icu2_read(MSYSINT2REG);
 
 	mask1 &= pend1;
 	mask2 &= pend2;
 
 	if (mask1) {
 		for (i = 0; i < 16; i++) {
-			if (intnum == sysint1_assign[i] &&
-			    (mask1 & ((uint16_t)1 << i))) {
-#ifdef CONFIG_GPIO_VR41XX
-				if (i == 8)
-					giuint_irq_dispatch(regs);
-				else
-#endif
-					do_IRQ(SYSINT1_IRQ(i), regs);
-				return;
-			}
+			if (irq == INT_TO_IRQ(sysint1_assign[i]) && (mask1 & (1 << i)))
+				return SYSINT1_IRQ(i);
 		}
 	}
 
 	if (mask2) {
 		for (i = 0; i < 16; i++) {
-			if (intnum == sysint2_assign[i] &&
-			    (mask2 & ((uint16_t)1 << i))) {
-				do_IRQ(SYSINT2_IRQ(i), regs);
-				return;
-			}
+			if (irq == INT_TO_IRQ(sysint2_assign[i]) && (mask2 & (1 << i)))
+				return SYSINT2_IRQ(i);
 		}
 	}
 
 	printk(KERN_ERR "spurious ICU interrupt: %04x,%04x\n", pend1, pend2);
 
 	atomic_inc(&irq_err_count);
-}
 
-/*=======================================================================*/
+	return -1;
+}
 
-static inline void init_vr41xx_icu_irq(void)
+static int __init vr41xx_icu_init(void)
 {
+	unsigned long icu1_start, icu2_start;
 	int i;
 
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		icu1_base = SYSINT1REG_TYPE1;
-		icu2_base = SYSINT2REG_TYPE1;
+		icu1_start = ICU1_TYPE1_BASE;
+		icu2_start = ICU2_TYPE1_BASE;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		icu1_base = SYSINT1REG_TYPE2;
-		icu2_base = SYSINT2REG_TYPE2;
+		icu1_start = ICU1_TYPE2_BASE;
+		icu2_start = ICU2_TYPE2_BASE;
 		break;
 	default:
 		printk(KERN_ERR "ICU: Unexpected CPU of NEC VR4100 series\n");
-		return -EINVAL;
+		return -ENODEV;
+	}
+
+	if (request_mem_region(icu1_start, ICU1_SIZE, "ICU") == NULL)
+		return -EBUSY;
+
+	if (request_mem_region(icu2_start, ICU2_SIZE, "ICU") == NULL) {
+		release_mem_region(icu1_start, ICU1_SIZE);
+		return -EBUSY;
+	}
+
+	icu1_base = ioremap(icu1_start, ICU1_SIZE);
+	if (icu1_base == NULL) {
+		release_mem_region(icu1_start, ICU1_SIZE);
+		release_mem_region(icu2_start, ICU2_SIZE);
+		return -ENOMEM;
+	}
+
+	icu2_base = ioremap(icu2_start, ICU2_SIZE);
+	if (icu2_base == NULL) {
+		iounmap(icu1_base);
+		release_mem_region(icu1_start, ICU1_SIZE);
+		release_mem_region(icu2_start, ICU2_SIZE);
+		return -ENOMEM;
 	}
 
-	write_icu1(0, MSYSINT1REG);
-	write_icu1(0xffff, MGIUINTLREG);
+	icu1_write(MSYSINT1REG, 0);
+	icu1_write(MGIUINTLREG, 0xffff);
 
-	write_icu2(0, MSYSINT2REG);
-	write_icu2(0xffff, MGIUINTHREG);
+	icu2_write(MSYSINT2REG, 0);
+	icu2_write(MGIUINTHREG, 0xffff);
 
 	for (i = SYSINT1_IRQ_BASE; i <= SYSINT1_IRQ_LAST; i++)
 		irq_desc[i].handler = &sysint1_irq_type;
@@ -735,20 +730,13 @@
 	for (i = SYSINT2_IRQ_BASE; i <= SYSINT2_IRQ_LAST; i++)
 		irq_desc[i].handler = &sysint2_irq_type;
 
-	setup_irq(INT0_CASCADE_IRQ, &icu_cascade);
-	setup_irq(INT1_CASCADE_IRQ, &icu_cascade);
-	setup_irq(INT2_CASCADE_IRQ, &icu_cascade);
-	setup_irq(INT3_CASCADE_IRQ, &icu_cascade);
-	setup_irq(INT4_CASCADE_IRQ, &icu_cascade);
-}
-
-void __init arch_init_irq(void)
-{
-	mips_cpu_irq_init(MIPS_CPU_IRQ_BASE);
-	init_vr41xx_icu_irq();
-#ifdef CONFIG_GPIO_VR41XX
-	init_vr41xx_giuint_irq();
-#endif
+	cascade_irq(INT0_IRQ, icu_get_irq);
+	cascade_irq(INT1_IRQ, icu_get_irq);
+	cascade_irq(INT2_IRQ, icu_get_irq);
+	cascade_irq(INT3_IRQ, icu_get_irq);
+	cascade_irq(INT4_IRQ, icu_get_irq);
 
-	set_except_vector(0, vr41xx_handle_interrupt);
+	return 0;
 }
+
+core_initcall(vr41xx_icu_init);
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/int-handler.S a/arch/mips/vr41xx/common/int-handler.S
--- a-orig/arch/mips/vr41xx/common/int-handler.S	Thu Dec 18 01:02:24 2003
+++ a/arch/mips/vr41xx/common/int-handler.S	Sat May 28 18:29:30 2005
@@ -71,24 +71,24 @@
 
 		andi	t1, t0, CAUSEF_IP3	# check for Int1
 		bnez	t1, handle_int
-		li	a0, 1
+		li	a0, 3
 
 		andi	t1, t0, CAUSEF_IP4	# check for Int2
 		bnez	t1, handle_int
-		li	a0, 2
+		li	a0, 4
 
 		andi	t1, t0, CAUSEF_IP5	# check for Int3
 		bnez	t1, handle_int
-		li	a0, 3
+		li	a0, 5
 
 		andi	t1, t0, CAUSEF_IP6	# check for Int4
 		bnez	t1, handle_int
-		li	a0, 4
+		li	a0, 6
 
 1:
 		andi	t1, t0, CAUSEF_IP2	# check for Int0
 		bnez	t1, handle_int
-		li	a0, 0
+		li	a0, 2
 
 		andi	t1, t0, CAUSEF_IP0	# check for IP0
 		bnez	t1, handle_irq
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/irq.c a/arch/mips/vr41xx/common/irq.c
--- a-orig/arch/mips/vr41xx/common/irq.c	Thu Jan  1 09:00:00 1970
+++ a/arch/mips/vr41xx/common/irq.c	Sat May 28 18:29:22 2005
@@ -0,0 +1,86 @@
+/*
+ *  Interrupt handing routines for NEC VR4100 series.
+ *
+ *  Copyright (C) 2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/interrupt.h>
+
+#include <asm/irq_cpu.h>
+#include <asm/system.h>
+#include <asm/vr41xx/vr41xx.h>
+
+typedef struct irq_cascade {
+	int (*get_irq)(unsigned int, struct pt_regs *);
+} irq_cascade_t;
+
+static irq_cascade_t irq_cascade[NR_IRQS] __cacheline_aligned;
+
+static struct irqaction cascade_irqaction = {
+	.handler	= no_action,
+	.mask		= CPU_MASK_NONE,
+	.name		= "cascade",
+};
+
+int cascade_irq(unsigned int irq, int (*get_irq)(unsigned int, struct pt_regs *))
+{
+	int retval = 0;
+
+	if (irq >= NR_IRQS)
+		return -EINVAL;
+
+	if (irq_cascade[irq].get_irq != NULL)
+		free_irq(irq, NULL);
+
+	irq_cascade[irq].get_irq = get_irq;
+
+	if (get_irq != NULL) {
+		retval = setup_irq(irq, &cascade_irqaction);
+		if (retval < 0)
+			irq_cascade[irq].get_irq = NULL;
+	}
+
+	return retval;
+}
+
+asmlinkage void irq_dispatch(unsigned int irq, struct pt_regs *regs)
+{
+	irq_cascade_t *cascade;
+
+	if (irq >= NR_IRQS) {
+		atomic_inc(&irq_err_count);
+		return;
+	}
+
+	cascade = irq_cascade + irq;
+	if (cascade->get_irq != NULL) {
+		irq = cascade->get_irq(irq, regs);
+		if (irq < 0)
+			atomic_inc(&irq_err_count);
+		else
+			irq_dispatch(irq, regs);
+	} else
+		do_IRQ(irq, regs);
+}
+
+extern asmlinkage void vr41xx_handle_interrupt(void);
+
+void __init arch_init_irq(void)
+{
+	mips_cpu_irq_init(MIPS_CPU_IRQ_BASE);
+
+	set_except_vector(0, vr41xx_handle_interrupt);
+}
diff -urN -X dontdiff a-orig/include/asm-mips/vr41xx/vr41xx.h a/include/asm-mips/vr41xx/vr41xx.h
--- a-orig/include/asm-mips/vr41xx/vr41xx.h	Fri May 20 07:27:42 2005
+++ a/include/asm-mips/vr41xx/vr41xx.h	Sat May 28 18:42:26 2005
@@ -79,11 +79,11 @@
 #define MIPS_CPU_IRQ(x)		(MIPS_CPU_IRQ_BASE + (x))
 #define MIPS_SOFTINT0_IRQ	MIPS_CPU_IRQ(0)
 #define MIPS_SOFTINT1_IRQ	MIPS_CPU_IRQ(1)
-#define INT0_CASCADE_IRQ	MIPS_CPU_IRQ(2)
-#define INT1_CASCADE_IRQ	MIPS_CPU_IRQ(3)
-#define INT2_CASCADE_IRQ	MIPS_CPU_IRQ(4)
-#define INT3_CASCADE_IRQ	MIPS_CPU_IRQ(5)
-#define INT4_CASCADE_IRQ	MIPS_CPU_IRQ(6)
+#define INT0_IRQ		MIPS_CPU_IRQ(2)
+#define INT1_IRQ		MIPS_CPU_IRQ(3)
+#define INT2_IRQ		MIPS_CPU_IRQ(4)
+#define INT3_IRQ		MIPS_CPU_IRQ(5)
+#define INT4_IRQ		MIPS_CPU_IRQ(6)
 #define TIMER_IRQ		MIPS_CPU_IRQ(7)
 
 /* SYINT1 Interrupt Numbers */
@@ -97,7 +97,7 @@
 #define PIU_IRQ			SYSINT1_IRQ(5)
 #define AIU_IRQ			SYSINT1_IRQ(6)
 #define KIU_IRQ			SYSINT1_IRQ(7)
-#define GIUINT_CASCADE_IRQ	SYSINT1_IRQ(8)
+#define GIUINT_IRQ		SYSINT1_IRQ(8)
 #define SIU_IRQ			SYSINT1_IRQ(9)
 #define BUSERR_IRQ		SYSINT1_IRQ(10)
 #define SOFTINT_IRQ		SYSINT1_IRQ(11)
@@ -129,7 +129,7 @@
 #define GIU_IRQ_TO_PIN(x)	((x) - GIU_IRQ_BASE)	/* Pin 0-31 */
 
 extern int vr41xx_set_intassign(unsigned int irq, unsigned char intassign);
-extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq));
+extern int cascade_irq(unsigned int irq, int (*get_irq)(unsigned int, struct pt_regs *));
 
 #define PIUINT_COMMAND		0x0040
 #define PIUINT_DATA		0x0020





From haukeh@pc-kiel.de Mon May 30 13:06:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 May 2005 13:06:17 +0100 (BST)
Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:58755 "EHLO
	natsmtp00.rzone.de") by linux-mips.org with ESMTP
	id <S8225408AbVE3MGB>; Mon, 30 May 2005 13:06:01 +0100
Received: from [192.168.128.50] (p548DD5D1.dip.t-dialin.net [84.141.213.209])
	by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j4UC5wqX017448
	for <linux-mips@linux-mips.org>; Mon, 30 May 2005 14:05:59 +0200 (MEST)
From:	Hauke Goos-Habermann <haukeh@pc-kiel.de>
To:	linux-mips@linux-mips.org
Subject: Re: CCA4 mapping
Date:	Mon, 30 May 2005 14:05:55 +0200
User-Agent: KMail/1.7.2
References: <200505261520.34985.haukeh@pc-kiel.de> <530c77f53c1c8706d6fd75a07ad091ca@embeddedalley.com>
In-Reply-To: <530c77f53c1c8706d6fd75a07ad091ca@embeddedalley.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200505301405.58180.haukeh@pc-kiel.de>
Return-Path: <haukeh@pc-kiel.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8021
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: haukeh@pc-kiel.de
Precedence: bulk
X-list: linux-mips

Am Donnerstag, 26. Mai 2005 21:39 schrieb Dan Malek:
> On May 26, 2005, at 9:20 AM, Hauke Goos-Habermann wrote:
> > Does anybody have an idea how to make the CCA4 mapping?
>
> In the mmap() entry for the driver:
>
> 	pgprot_val(vma->vm_page_prot) |= (4 << 9);	/* CCA4 */
This is what I tried earlier. It doesn't speed up the driver. Enabling the 
caching with setting the CMEM register doesn't help too.

> or, whatever is appropriate.  This will only work from a user
> application (like X-Windows) that mmaps() the driver, you
> aren't going to get a kernel mapped space this way without
> some special VM space hacking.
I think that's what I need. The normal framebuffer driver is very slow and I 
need a faster and direct access to the video memory.

That's why I tried to use the add_wired_entry function. There I can enable the 
CCA4 and make a wired entry. But this doesn't work either:

add_wired_entry((0x00800000 >> 2) | 0x0027, (0x00900000 >> 2) | 0x0027, 
0x30000000 | 0x0027, 0x01ffe000);
add_wired_entry((0x00a00000 >> 2) | 0x0027, (0x00a00000 >> 2) | 0x0027, 
0x32000000 | 0x0027, 0x01ffe000);

The graphic card is a FUJITSU MB86290. Does anybody have experiences with this 
device?

Does anybody have an idea how to make the access to the video memory faster?

> Thanks.
>
> 	-- Dan
Cu Hauke

From spodstavin@ru.mvista.com Mon May 30 15:54:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 May 2005 15:54:48 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:16010 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225479AbVE3Oyd>; Mon, 30 May 2005 15:54:33 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4UEsWt25088
	for <linux-mips@linux-mips.org>; Mon, 30 May 2005 19:54:32 +0500
Subject: A new LSP for NEC VR5701-SG2 Board
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	linux-mips@linux-mips.org
Content-Type: text/plain
Organization: MontaVista
Date:	Mon, 30 May 2005 18:54:48 +0400
Message-Id: <1117464888.14501.12.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Content-Transfer-Encoding: 7bit
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8022
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips

Hi!

I have A new LSP for NEC VR5701-SG2 Board with CPU Vr5701, based on
Vr5500 core. What should I do in order to commit it to linux-mips
kernel?
Thanks.

Best wishes,
Sergey Podstavin,
software engineer,
MontaVista Inc.


From yuasa@hh.iij4u.or.jp Mon May 30 16:41:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 May 2005 16:42:04 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:55797 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224773AbVE3Plt>;
	Mon, 30 May 2005 16:41:49 +0100
Received: MO(mo01)id j4UFfj3n014178; Tue, 31 May 2005 00:41:45 +0900 (JST)
Received: MDO(mdo01) id j4UFfiff007739; Tue, 31 May 2005 00:41:45 +0900 (JST)
Received: from stratos (h042.p502.iij4u.or.jp [210.149.246.42])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j4UFfh2B017122
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 31 May 2005 00:41:43 +0900 (JST)
Date:	Tue, 31 May 2005 00:41:42 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	spodstavin@ru.mvista.com
Cc:	linux-mips@linux-mips.org
Subject: Re: A new LSP for NEC VR5701-SG2 Board
Message-Id: <20050531004142.0cc26a04.yuasa@hh.iij4u.or.jp>
In-Reply-To: <1117464888.14501.12.camel@localhost.localdomain>
References: <1117464888.14501.12.camel@localhost.localdomain>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8023
X-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,

On Mon, 30 May 2005 18:54:48 +0400
Sergey Podstavin <spodstavin@ru.mvista.com> wrote:

> Hi!
> 
> I have A new LSP for NEC VR5701-SG2 Board with CPU Vr5701, based on
> Vr5500 core. What should I do in order to commit it to linux-mips
> kernel?

You can see "Documentation/SubmittingPatches" in kernel source.

Yoichi


From maxim.osipov@gmail.com Tue May 31 09:57:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 09:57:51 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.197]:63009 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8225736AbVEaI5f> convert rfc822-to-8bit;
	Tue, 31 May 2005 09:57:35 +0100
Received: by zproxy.gmail.com with SMTP id 13so2793462nzp
        for <linux-mips@linux-mips.org>; Tue, 31 May 2005 01:57:28 -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:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=bekF4JTerbktsBY0wzbblmMUGOHjS4YJbccSPQBX18Uy1B75sOdn5y+8ktEIjV1ywb9HE10UHpmdSm0EKnOrIikCGXfwwHR6HcTZTyVe3rm/IQp2CHrMFOspD3lNndrGnxY987FM3QNX9cxxUUMgC0/b42M+UszOHHu2uvDGIzA=
Received: by 10.36.71.16 with SMTP id t16mr2122236nza;
        Tue, 31 May 2005 01:57:28 -0700 (PDT)
Received: by 10.36.68.6 with HTTP; Tue, 31 May 2005 01:57:28 -0700 (PDT)
Message-ID: <6097c4905053101574dbde215@mail.gmail.com>
Date:	Tue, 31 May 2005 12:57:28 +0400
From:	Maxim Osipov <maxim.osipov@gmail.com>
Reply-To: maxim@mox.ru
To:	linux-mips@linux-mips.org
Subject: toolchain sources
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <maxim.osipov@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8024
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maxim.osipov@gmail.com
Precedence: bulk
X-list: linux-mips

Hello,

Does anyone know, where can I find SRPMS (or sources + patches) for
the following toolchains:

ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux/binutils-2.15/
ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mips64-linux/gcc-3.4.3/

Thank you in advance!

Best regards,
Maxim

From jerry@wicomtechnologies.com Tue May 31 10:09:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 10:09:59 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:61125
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8225741AbVEaJJn>; Tue, 31 May 2005 10:09:43 +0100
Received: from [192.168.0.24] (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j4V99a5K036312
	for <linux-mips@linux-mips.org>; Tue, 31 May 2005 12:09:36 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Tue, 31 May 2005 12:11:04 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.0.1.33) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <1117396240.20050531121104@wicomtechnologies.com>
To:	linux-mips <linux-mips@linux-mips.org>
Subject: au1200 MAE drivers
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8025
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips


 Hello.

 I found Linux 2.4 binary packages on ftp.amd.com including au1200 MAE
driver and some video decoders. I see these lines in driver
"author=Scott Bolton" and "license=GPL", but without any contact info.
Does anyone have any information about the author, or where these
sources can be obtained? (excluding official AMD channels, it's
already in proress without any hope for success)
  

   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.0.1.33>- -<31/05/2005 11:53>-
  (") (")


From spodstavin@ru.mvista.com Tue May 31 13:27:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 13:28:19 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:5519 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225765AbVEaM14>; Tue, 31 May 2005 13:27:56 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4VCRpt03727;
	Tue, 31 May 2005 17:27:52 +0500
Subject: [PATCH] A sound driver for NEC VR5701-SG2 Board
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	andrewtv@usa.net
Cc:	linux-mips <linux-mips@linux-mips.org>
Content-Type: multipart/mixed; boundary="=-OPaFC3FnAr8zyaHKvnnd"
Organization: MontaVista
Date:	Tue, 31 May 2005 16:28:09 +0400
Message-Id: <1117542489.5564.11.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8026
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Andrew!

Attached is a sound driver for NEC VR5701-SG2 Board. It's a Vr5701 CPU's
internal AC97 Interface. The driver works with AC97 Codec.


--=-OPaFC3FnAr8zyaHKvnnd
Content-Disposition: attachment; filename=community_mips_nec_vr5701_sound.patch
Content-Type: text/x-patch; name=community_mips_nec_vr5701_sound.patch; charset=UTF-8
Content-Transfer-Encoding: 7bit

diff -Naurp --exclude=CVS linux_mips_save/sound/oss/Kconfig linux_mips/sound/oss/Kconfig
--- linux_mips_save/sound/oss/Kconfig	2005-04-29 15:15:23.000000000 +0400
+++ linux_mips/sound/oss/Kconfig	2005-05-31 15:40:52.000000000 +0400
@@ -216,6 +216,13 @@ config SOUND_VRC5477
 	  integrated, multi-function controller chip for MIPS CPUs.  Works
 	  with the AC97 codec.
 
+config SOUND_VR5701
+	tristate "NEC VR5701-SG2 AC97 sound"
+	depends on SOUND_PRIME!=n && TCUBE && SOUND
+	help
+	  Say Y here to enable sound support for the NEC VR5701-SG2 AC97 sound.
+	  Works with the AC97 codec.
+
 config SOUND_AU1000
 	tristate "Au1000 Sound"
 	depends on SOUND_PRIME!=n && (SOC_AU1000 || SOC_AU1100 || SOC_AU1500) && SOUND
diff -Naurp --exclude=CVS linux_mips_save/sound/oss/Makefile linux_mips/sound/oss/Makefile
--- linux_mips_save/sound/oss/Makefile	2005-01-31 08:45:30.000000000 +0300
+++ linux_mips/sound/oss/Makefile	2005-05-31 15:40:52.000000000 +0400
@@ -64,6 +64,7 @@ endif
 obj-$(CONFIG_SOUND_ES1370)	+= es1370.o
 obj-$(CONFIG_SOUND_ES1371)	+= es1371.o ac97_codec.o
 obj-$(CONFIG_SOUND_VRC5477)	+= nec_vrc5477.o ac97_codec.o
+obj-$(CONFIG_SOUND_VR5701)	+= nec_vr5701_sg2.o ac97_codec.o
 obj-$(CONFIG_SOUND_AU1000)	+= au1000.o ac97_codec.o  
 obj-$(CONFIG_SOUND_AU1550_AC97)	+= au1550_ac97.o ac97_codec.o  
 obj-$(CONFIG_SOUND_AU1550_I2S)	+= au1550_i2s.o  
diff -Naurp --exclude=CVS linux_mips_save/sound/oss/nec_vr5701_sg2.c linux_mips/sound/oss/nec_vr5701_sg2.c
--- linux_mips_save/sound/oss/nec_vr5701_sg2.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/sound/oss/nec_vr5701_sg2.c	2005-05-31 15:40:52.000000000 +0400
@@ -0,0 +1,1355 @@
+/*
+ * sound/oss/nec_vr5701_sg2.c
+ *
+ * An AC97 sounf driver for NEC VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include "nec_vr5701_sg2.h"
+
+static LIST_HEAD(devs);
+
+static u16 rdcodec(struct ac97_codec *codec, u8 addr)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)codec->private_data;
+	unsigned long flags;
+	u32 result;
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	/* wait until we can access codec registers */
+	while (inl(s->io + vr5701_CODEC_WR) & 0x80000000) ;
+
+	/* write the address and "read" command to codec */
+	addr = addr & 0x7f;
+	outl((addr << 16) | vr5701_CODEC_WR_RWC, s->io + vr5701_CODEC_WR);
+
+	/* get the return result */
+	udelay(100);		/* workaround hardware bug */
+	while ((result = inl(s->io + vr5701_CODEC_RD)) &
+	       (vr5701_CODEC_RD_RRDYA | vr5701_CODEC_RD_RRDYD)) {
+		/* we get either addr or data, or both */
+		if (result & vr5701_CODEC_RD_RRDYA) {
+			ASSERT(addr == ((result >> 16) & 0x7f));
+		}
+		if (result & vr5701_CODEC_RD_RRDYD) {
+			break;
+		}
+	}
+
+	spin_unlock_irqrestore(&s->lock, flags);
+
+	return result & 0xffff;
+}
+
+static void wrcodec(struct ac97_codec *codec, u8 addr, u16 data)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)codec->private_data;
+	unsigned long flags;
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	/* wait until we can access codec registers */
+	while (inl(s->io + vr5701_CODEC_WR) & 0x80000000) ;
+
+	/* write the address and value to codec */
+	outl((addr << 16) | data, s->io + vr5701_CODEC_WR);
+
+	spin_unlock_irqrestore(&s->lock, flags);
+}
+
+static void waitcodec(struct ac97_codec *codec)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)codec->private_data;
+
+	/* wait until we can access codec registers */
+	while (inl(s->io + vr5701_CODEC_WR) & 0x80000000) ;
+}
+
+static void vr5701_ac97_delay(int msec)
+{
+	unsigned long tmo;
+	signed long tmo2;
+
+	if (in_interrupt())
+		return;
+
+	tmo = jiffies + (msec * HZ) / 1000;
+	for (;;) {
+		tmo2 = tmo - jiffies;
+		if (tmo2 <= 0)
+			break;
+		schedule_timeout(tmo2);
+	}
+}
+
+static void set_adc_rate(struct vr5701_ac97_state *s, unsigned rate)
+{
+	wrcodec(s->codec, AC97_PCM_LR_ADC_RATE, rate);
+	s->adcRate = rate;
+}
+
+static void set_dac_rate(struct vr5701_ac97_state *s, unsigned rate)
+{
+	if (s->extended_status & AC97_EXTSTAT_VRA) {
+		wrcodec(s->codec, AC97_PCM_FRONT_DAC_RATE, rate);
+		s->dacRate = rdcodec(s->codec, AC97_PCM_FRONT_DAC_RATE);
+	}
+}
+
+static void start_dac(struct vr5701_ac97_state *s)
+{
+	struct dmabuf *db = &s->dma_dac;
+	unsigned long flags;
+	u32 dmaLength;
+	u32 temp;
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	if (!db->stopped) {
+		spin_unlock_irqrestore(&s->lock, flags);
+		return;
+	}
+
+	/* we should have some data to do the DMA trasnfer */
+	ASSERT(db->count >= db->fragSize);
+
+	/* clear pending fales interrupts */
+	outl(vr5701_INT_MASK_DAC1END | vr5701_INT_MASK_DAC2END,
+	     s->io + vr5701_INT_CLR);
+
+	/* enable interrupts */
+	temp = inl(s->io + vr5701_INT_MASK);
+	temp |= vr5701_INT_MASK_DAC1END | vr5701_INT_MASK_DAC2END;
+	outl(temp, s->io + vr5701_INT_MASK);
+
+	/* setup dma base addr */
+	outl(db->lbufDma + db->nextOut, s->io + vr5701_DAC1_BADDR);
+	if (s->dacChannels == 1) {
+		outl(db->lbufDma + db->nextOut, s->io + vr5701_DAC2_BADDR);
+	} else {
+		outl(db->rbufDma + db->nextOut, s->io + vr5701_DAC2_BADDR);
+	}
+
+	/* set dma length, in the unit of 0x10 bytes */
+	dmaLength = db->fragSize >> 4;
+	outl(dmaLength, s->io + vr5701_DAC1L);
+	outl(dmaLength, s->io + vr5701_DAC2L);
+
+	/* activate dma */
+	outl(vr5701_DMA_ACTIVATION, s->io + vr5701_DAC1_CTRL);
+	outl(vr5701_DMA_ACTIVATION, s->io + vr5701_DAC2_CTRL);
+
+	/* enable dac slots - we should hear the music now! */
+	temp = inl(s->io + vr5701_CTRL);
+	temp |= (vr5701_CTRL_DAC1ENB | vr5701_CTRL_DAC2ENB);
+	outl(temp, s->io + vr5701_CTRL);
+
+	/* it is time to setup next dma transfer */
+	ASSERT(inl(s->io + vr5701_DAC1_CTRL) & vr5701_DMA_WIP);
+	ASSERT(inl(s->io + vr5701_DAC2_CTRL) & vr5701_DMA_WIP);
+
+	temp = db->nextOut + db->fragSize;
+	if (temp >= db->fragTotalSize) {
+		ASSERT(temp == db->fragTotalSize);
+		temp = 0;
+	}
+
+	outl(db->lbufDma + temp, s->io + vr5701_DAC1_BADDR);
+	if (s->dacChannels == 1) {
+		outl(db->lbufDma + temp, s->io + vr5701_DAC2_BADDR);
+	} else {
+		outl(db->rbufDma + temp, s->io + vr5701_DAC2_BADDR);
+	}
+
+	db->stopped = 0;
+
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+	outTicket = *(u16 *) (db->lbuf + db->nextOut);
+	if (db->count > db->fragSize) {
+		ASSERT((u16) (outTicket + 1) == *(u16 *) (db->lbuf + temp));
+	}
+#endif
+	spin_unlock_irqrestore(&s->lock, flags);
+}
+
+static void start_adc(struct vr5701_ac97_state *s)
+{
+	struct dmabuf *db = &s->dma_adc;
+	unsigned long flags;
+	u32 dmaLength;
+	u32 temp;
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	if (!db->stopped) {
+		spin_unlock_irqrestore(&s->lock, flags);
+		return;
+	}
+
+	/* we should at least have some free space in the buffer */
+	ASSERT(db->count < db->fragTotalSize - db->fragSize * 2);
+
+	/* clear pending ones */
+	outl(vr5701_INT_MASK_ADC1END | vr5701_INT_MASK_ADC2END,
+	     s->io + vr5701_INT_CLR);
+
+	/* enable interrupts */
+	temp = inl(s->io + vr5701_INT_MASK);
+	temp |= vr5701_INT_MASK_ADC1END | vr5701_INT_MASK_ADC2END;
+	outl(temp, s->io + vr5701_INT_MASK);
+
+	/* setup dma base addr */
+	outl(db->lbufDma + db->nextIn, s->io + vr5701_ADC1_BADDR);
+	outl(db->rbufDma + db->nextIn, s->io + vr5701_ADC2_BADDR);
+
+	/* setup dma length */
+	dmaLength = db->fragSize >> 4;
+	outl(dmaLength, s->io + vr5701_ADC1L);
+	outl(dmaLength, s->io + vr5701_ADC2L);
+
+	/* activate dma */
+	outl(vr5701_DMA_ACTIVATION, s->io + vr5701_ADC1_CTRL);
+	outl(vr5701_DMA_ACTIVATION, s->io + vr5701_ADC2_CTRL);
+
+	/* enable adc slots */
+	temp = inl(s->io + vr5701_CTRL);
+	temp |= (vr5701_CTRL_ADC1ENB | vr5701_CTRL_ADC2ENB);
+	outl(temp, s->io + vr5701_CTRL);
+
+	/* it is time to setup next dma transfer */
+	temp = db->nextIn + db->fragSize;
+	if (temp >= db->fragTotalSize) {
+		ASSERT(temp == db->fragTotalSize);
+		temp = 0;
+	}
+	outl(db->lbufDma + temp, s->io + vr5701_ADC1_BADDR);
+	outl(db->rbufDma + temp, s->io + vr5701_ADC2_BADDR);
+
+	db->stopped = 0;
+
+	spin_unlock_irqrestore(&s->lock, flags);
+}
+
+/* return the total bytes that is copied */
+static inline int
+copy_dac_from_user(struct vr5701_ac97_state *s,
+		   const char *buffer, size_t count, int avail)
+{
+	struct dmabuf *db = &s->dma_dac;
+	int copyCount = 0;
+	int copyFragCount = 0;
+	int totalCopyCount = 0;
+	int totalCopyFragCount = 0;
+	unsigned long flags;
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+	int i;
+#endif
+
+	/* adjust count to signel channel byte count */
+	count >>= s->dacChannels - 1;
+
+	/* we may have to "copy" twice as ring buffer wraps around */
+	for (; (avail > 0) && (count > 0);) {
+		/* determine max possible copy count for single channel */
+		copyCount = count;
+		if (copyCount > avail) {
+			copyCount = avail;
+		}
+		if (copyCount + db->nextIn > db->fragTotalSize) {
+			copyCount = db->fragTotalSize - db->nextIn;
+			ASSERT(copyCount > 0);
+		}
+
+		copyFragCount = copyCount;
+		ASSERT(copyFragCount >= copyCount);
+
+		/* we copy differently based on the number channels */
+		if (s->dacChannels == 1) {
+			if (copy_from_user(db->lbuf + db->nextIn,
+					   buffer, copyCount))
+				return -1;
+			/* fill gaps with 0 */
+			memset(db->lbuf + db->nextIn + copyCount,
+			       0, copyFragCount - copyCount);
+		} else {
+			/* we have demux the stream into two separate ones */
+			if (copy_two_channel_dac_from_user
+			    (s, buffer, copyCount))
+				return -1;
+			/* fill gaps with 0 */
+			memset(db->lbuf + db->nextIn + copyCount,
+			       0, copyFragCount - copyCount);
+			memset(db->rbuf + db->nextIn + copyCount,
+			       0, copyFragCount - copyCount);
+		}
+
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+		for (i = 0; i < copyFragCount; i += db->fragSize) {
+			*(u16 *) (db->lbuf + db->nextIn + i) = inTicket++;
+		}
+#endif
+
+		count -= copyCount;
+		totalCopyCount += copyCount;
+		avail -= copyFragCount;
+		totalCopyFragCount += copyFragCount;
+
+		buffer += copyCount << (s->dacChannels - 1);
+
+		db->nextIn += copyFragCount;
+		if (db->nextIn >= db->fragTotalSize) {
+			ASSERT(db->nextIn == db->fragTotalSize);
+			db->nextIn = 0;
+		}
+
+		ASSERT((count == 0) || (copyCount == copyFragCount));
+	}
+
+	spin_lock_irqsave(&s->lock, flags);
+	db->count += totalCopyFragCount;
+	if (db->stopped) {
+		start_dac(s);
+	}
+
+	/* nextIn should not be equal to nextOut unless we are full */
+	ASSERT(((db->count == db->fragTotalSize) &&
+		(db->nextIn == db->nextOut)) ||
+	       ((db->count < db->fragTotalSize) &&
+		(db->nextIn != db->nextOut)));
+
+	spin_unlock_irqrestore(&s->lock, flags);
+
+	return totalCopyCount << (s->dacChannels - 1);
+
+}
+
+static int prog_dmabuf(struct vr5701_ac97_state *s,
+		       struct dmabuf *db, unsigned rate)
+{
+	int order;
+	unsigned bufsize;
+
+	if (!db->lbuf) {
+		ASSERT(!db->rbuf);
+
+		db->ready = 0;
+		for (order = DMABUF_DEFAULTORDER;
+		     order >= DMABUF_MINORDER; order--) {
+			db->lbuf = pci_alloc_consistent(s->dev,
+							PAGE_SIZE << order,
+							&db->lbufDma);
+			db->rbuf = pci_alloc_consistent(s->dev,
+							PAGE_SIZE << order,
+							&db->rbufDma);
+			if (db->lbuf && db->rbuf)
+				break;
+			if (db->lbuf) {
+				ASSERT(!db->rbuf);
+				pci_free_consistent(s->dev,
+						    PAGE_SIZE << order,
+						    db->lbuf, db->lbufDma);
+			}
+		}
+		if (!db->lbuf) {
+			ASSERT(!db->rbuf);
+			return -ENOMEM;
+		}
+
+		db->bufOrder = order;
+	}
+
+	db->count = 0;
+	db->nextIn = db->nextOut = 0;
+
+	bufsize = PAGE_SIZE << db->bufOrder;
+	db->fragShift = ld2(rate * 2 / 100);
+	if (db->fragShift < 4)
+		db->fragShift = 4;
+
+	db->numFrag = bufsize >> db->fragShift;
+	while (db->numFrag < 4 && db->fragShift > 4) {
+		db->fragShift--;
+		db->numFrag = bufsize >> db->fragShift;
+	}
+	db->fragSize = 1 << db->fragShift;
+	db->fragTotalSize = db->numFrag << db->fragShift;
+	memset(db->lbuf, 0, db->fragTotalSize);
+	memset(db->rbuf, 0, db->fragTotalSize);
+
+	db->ready = 1;
+
+	return 0;
+}
+
+static irqreturn_t vr5701_ac97_interrupt(int irq, void *dev_id,
+					 struct pt_regs *regs)
+{
+	struct vr5701_ac97_state *s = (struct vr5701_ac97_state *)dev_id;
+	u32 irqStatus;
+	u32 adcInterrupts, dacInterrupts;
+
+	spin_lock(&s->lock);
+
+	/* get irqStatus and clear the detected ones */
+	irqStatus = inl(s->io + vr5701_INT_STATUS);
+	outl(irqStatus, s->io + vr5701_INT_CLR);
+
+	/* let us see what we get */
+	dacInterrupts = vr5701_INT_MASK_DAC1END | vr5701_INT_MASK_DAC2END;
+	adcInterrupts = vr5701_INT_MASK_ADC1END | vr5701_INT_MASK_ADC2END;
+	if (irqStatus & dacInterrupts) {
+		/* we should get both interrupts, but just in case ...  */
+		if (irqStatus & vr5701_INT_MASK_DAC1END) {
+			vr5701_ac97_dac_interrupt(s);
+		}
+		if ((irqStatus & dacInterrupts) != dacInterrupts) {
+			printk(KERN_WARNING
+			       "vr5701_ac97 : dac interrupts not in sync!!!\n");
+			stop_dac(s);
+			start_dac(s);
+		}
+	} else if (irqStatus & adcInterrupts) {
+		/* we should get both interrupts, but just in case ...  */
+		if (irqStatus & vr5701_INT_MASK_ADC1END) {
+			vr5701_ac97_adc_interrupt(s);
+		}
+		if ((irqStatus & adcInterrupts) != adcInterrupts) {
+			printk(KERN_WARNING
+			       "vr5701_ac97 : adc interrupts not in sync!!!\n");
+			stop_adc(s);
+			start_adc(s);
+		}
+	}
+
+	spin_unlock(&s->lock);
+	return IRQ_HANDLED;
+}
+
+static int vr5701_ac97_open_mixdev(struct inode *inode, struct file *file)
+{
+	int minor = iminor(inode);
+	struct list_head *list;
+	struct vr5701_ac97_state *s;
+
+	for (list = devs.next;; list = list->next) {
+		if (list == &devs)
+			return -ENODEV;
+		s = list_entry(list, struct vr5701_ac97_state, devs);
+		if (s->codec->dev_mixer == minor)
+			break;
+	}
+	file->private_data = s;
+	return nonseekable_open(inode, file);
+}
+
+static int vr5701_ac97_release_mixdev(struct inode *inode, struct file *file)
+{
+	return 0;
+}
+
+static int mixdev_ioctl(struct ac97_codec *codec, unsigned int cmd,
+			unsigned long arg)
+{
+	return codec->mixer_ioctl(codec, cmd, arg);
+}
+
+static int vr5701_ac97_ioctl_mixdev(struct inode *inode, struct file *file,
+				    unsigned int cmd, unsigned long arg)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)file->private_data;
+	struct ac97_codec *codec = s->codec;
+
+	return mixdev_ioctl(codec, cmd, arg);
+}
+
+static struct file_operations vr5701_ac97_mixer_fops = {
+	.owner = THIS_MODULE,
+	.llseek = no_llseek,
+	.ioctl = vr5701_ac97_ioctl_mixdev,
+	.open = vr5701_ac97_open_mixdev,
+	.release = vr5701_ac97_release_mixdev,
+};
+
+static int drain_dac(struct vr5701_ac97_state *s, int nonblock)
+{
+	unsigned long flags;
+	int count, tmo;
+
+	if (!s->dma_dac.ready)
+		return 0;
+
+	for (;;) {
+		spin_lock_irqsave(&s->lock, flags);
+		count = s->dma_dac.count;
+		spin_unlock_irqrestore(&s->lock, flags);
+		if (count <= 0)
+			break;
+		if (signal_pending(current))
+			break;
+		if (nonblock)
+			return -EBUSY;
+		tmo = 1000 * count / s->dacRate / 2;
+		vr5701_ac97_delay(tmo);
+	}
+	if (signal_pending(current))
+		return -ERESTARTSYS;
+	return 0;
+}
+
+static ssize_t
+vr5701_ac97_read(struct file *file, char *buffer, size_t count, loff_t * ppos)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)file->private_data;
+	struct dmabuf *db = &s->dma_adc;
+	ssize_t ret = 0;
+	unsigned long flags;
+	int copyCount;
+	size_t avail;
+
+	if (!access_ok(VERIFY_WRITE, buffer, count))
+		return -EFAULT;
+
+	ASSERT(db->ready);
+
+	while (count > 0) {
+		do {
+			spin_lock_irqsave(&s->lock, flags);
+			if (db->stopped)
+				start_adc(s);
+			avail = db->count;
+			spin_unlock_irqrestore(&s->lock, flags);
+			if (avail <= 0) {
+				if (file->f_flags & O_NONBLOCK) {
+					if (!ret)
+						ret = -EAGAIN;
+					return ret;
+				}
+				interruptible_sleep_on(&db->wait);
+				if (signal_pending(current)) {
+					if (!ret)
+						ret = -ERESTARTSYS;
+					return ret;
+				}
+			}
+		} while (avail <= 0);
+
+		ASSERT((avail % db->fragSize) == 0);
+		copyCount = copy_adc_to_user(s, buffer, count, avail);
+		if (copyCount <= 0) {
+			if (!ret)
+				ret = -EFAULT;
+			return ret;
+		}
+
+		count -= copyCount;
+		buffer += copyCount;
+		ret += copyCount;
+	}
+
+	return ret;
+}
+
+static ssize_t vr5701_ac97_write(struct file *file, const char *buffer,
+				 size_t count, loff_t * ppos)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)file->private_data;
+	struct dmabuf *db = &s->dma_dac;
+	ssize_t ret;
+	unsigned long flags;
+	int copyCount, avail;
+
+	if (!access_ok(VERIFY_READ, buffer, count))
+		return -EFAULT;
+	ret = 0;
+
+	while (count > 0) {
+		do {
+			spin_lock_irqsave(&s->lock, flags);
+			avail = db->fragTotalSize - db->count;
+			spin_unlock_irqrestore(&s->lock, flags);
+			if (avail <= 0) {
+				if (file->f_flags & O_NONBLOCK) {
+					if (!ret)
+						ret = -EAGAIN;
+					return ret;
+				}
+				interruptible_sleep_on(&db->wait);
+				if (signal_pending(current)) {
+					if (!ret)
+						ret = -ERESTARTSYS;
+					return ret;
+				}
+			}
+		} while (avail <= 0);
+
+		copyCount = copy_dac_from_user(s, buffer, count, avail);
+		if (copyCount < 0) {
+			if (!ret)
+				ret = -EFAULT;
+			return ret;
+		}
+
+		count -= copyCount;
+		buffer += copyCount;
+		ret += copyCount;
+	}
+
+	return ret;
+}
+
+/* No kernel lock - we have our own spinlock */
+static unsigned int vr5701_ac97_poll(struct file *file,
+				     struct poll_table_struct *wait)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)file->private_data;
+	unsigned long flags;
+	unsigned int mask = 0;
+
+	if (file->f_mode & FMODE_WRITE)
+		poll_wait(file, &s->dma_dac.wait, wait);
+	if (file->f_mode & FMODE_READ)
+		poll_wait(file, &s->dma_adc.wait, wait);
+	spin_lock_irqsave(&s->lock, flags);
+	if (file->f_mode & FMODE_READ) {
+		if (s->dma_adc.count >= (signed)s->dma_adc.fragSize)
+			mask |= POLLIN | POLLRDNORM;
+	}
+	if (file->f_mode & FMODE_WRITE) {
+		if ((signed)s->dma_dac.fragTotalSize >=
+		    s->dma_dac.count + (signed)s->dma_dac.fragSize)
+			mask |= POLLOUT | POLLWRNORM;
+	}
+	spin_unlock_irqrestore(&s->lock, flags);
+	return mask;
+}
+
+#ifdef vr5701_AC97_DEBUG
+static struct ioctl_str_t {
+	unsigned int cmd;
+	const char *str;
+} ioctl_str[] = {
+	{
+	SNDCTL_DSP_RESET, "SNDCTL_DSP_RESET"}, {
+	SNDCTL_DSP_SYNC, "SNDCTL_DSP_SYNC"}, {
+	SNDCTL_DSP_SPEED, "SNDCTL_DSP_SPEED"}, {
+	SNDCTL_DSP_STEREO, "SNDCTL_DSP_STEREO"}, {
+	SNDCTL_DSP_GETBLKSIZE, "SNDCTL_DSP_GETBLKSIZE"}, {
+	SNDCTL_DSP_SETFMT, "SNDCTL_DSP_SETFMT"}, {
+	SNDCTL_DSP_SAMPLESIZE, "SNDCTL_DSP_SAMPLESIZE"}, {
+	SNDCTL_DSP_CHANNELS, "SNDCTL_DSP_CHANNELS"}, {
+	SOUND_PCM_WRITE_CHANNELS, "SOUND_PCM_WRITE_CHANNELS"}, {
+	SOUND_PCM_WRITE_FILTER, "SOUND_PCM_WRITE_FILTER"}, {
+	SNDCTL_DSP_POST, "SNDCTL_DSP_POST"}, {
+	SNDCTL_DSP_SUBDIVIDE, "SNDCTL_DSP_SUBDIVIDE"}, {
+	SNDCTL_DSP_SETFRAGMENT, "SNDCTL_DSP_SETFRAGMENT"}, {
+	SNDCTL_DSP_GETFMTS, "SNDCTL_DSP_GETFMTS"}, {
+	SNDCTL_DSP_GETOSPACE, "SNDCTL_DSP_GETOSPACE"}, {
+	SNDCTL_DSP_GETISPACE, "SNDCTL_DSP_GETISPACE"}, {
+	SNDCTL_DSP_NONBLOCK, "SNDCTL_DSP_NONBLOCK"}, {
+	SNDCTL_DSP_GETCAPS, "SNDCTL_DSP_GETCAPS"}, {
+	SNDCTL_DSP_GETTRIGGER, "SNDCTL_DSP_GETTRIGGER"}, {
+	SNDCTL_DSP_SETTRIGGER, "SNDCTL_DSP_SETTRIGGER"}, {
+	SNDCTL_DSP_GETIPTR, "SNDCTL_DSP_GETIPTR"}, {
+	SNDCTL_DSP_GETOPTR, "SNDCTL_DSP_GETOPTR"}, {
+	SNDCTL_DSP_MAPINBUF, "SNDCTL_DSP_MAPINBUF"}, {
+	SNDCTL_DSP_MAPOUTBUF, "SNDCTL_DSP_MAPOUTBUF"}, {
+	SNDCTL_DSP_SETSYNCRO, "SNDCTL_DSP_SETSYNCRO"}, {
+	SNDCTL_DSP_SETDUPLEX, "SNDCTL_DSP_SETDUPLEX"}, {
+	SNDCTL_DSP_GETODELAY, "SNDCTL_DSP_GETODELAY"}, {
+	SNDCTL_DSP_GETCHANNELMASK, "SNDCTL_DSP_GETCHANNELMASK"}, {
+	SNDCTL_DSP_BIND_CHANNEL, "SNDCTL_DSP_BIND_CHANNEL"}, {
+	OSS_GETVERSION, "OSS_GETVERSION"}, {
+	SOUND_PCM_READ_RATE, "SOUND_PCM_READ_RATE"}, {
+	SOUND_PCM_READ_CHANNELS, "SOUND_PCM_READ_CHANNELS"}, {
+	SOUND_PCM_READ_BITS, "SOUND_PCM_READ_BITS"}, {
+	SOUND_PCM_READ_FILTER, "SOUND_PCM_READ_FILTER"}
+};
+#endif
+
+static int vr5701_ac97_ioctl(struct inode *inode, struct file *file,
+			     unsigned int cmd, unsigned long arg)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)file->private_data;
+	unsigned long flags;
+	audio_buf_info abinfo;
+	int count;
+	int val, ret;
+
+#ifdef vr5701_AC97_DEBUG
+	for (count = 0; count < sizeof(ioctl_str) / sizeof(ioctl_str[0]);
+	     count++) {
+		if (ioctl_str[count].cmd == cmd)
+			break;
+	}
+	if (count < sizeof(ioctl_str) / sizeof(ioctl_str[0]))
+		printk(KERN_INFO PFX "ioctl %s\n", ioctl_str[count].str);
+	else
+		printk(KERN_INFO PFX "ioctl unknown, 0x%x\n", cmd);
+#endif
+
+	switch (cmd) {
+	case OSS_GETVERSION:
+		return put_user(SOUND_VERSION, (int *)arg);
+
+	case SNDCTL_DSP_SYNC:
+		if (file->f_mode & FMODE_WRITE)
+			return drain_dac(s, file->f_flags & O_NONBLOCK);
+		return 0;
+
+	case SNDCTL_DSP_SETDUPLEX:
+		return 0;
+
+	case SNDCTL_DSP_GETCAPS:
+		return put_user(DSP_CAP_DUPLEX, (int *)arg);
+
+	case SNDCTL_DSP_RESET:
+		if (file->f_mode & FMODE_WRITE) {
+			stop_dac(s);
+			synchronize_irq(s->irq);
+			s->dma_dac.count = 0;
+			s->dma_dac.nextIn = s->dma_dac.nextOut = 0;
+		}
+		if (file->f_mode & FMODE_READ) {
+			stop_adc(s);
+			synchronize_irq(s->irq);
+			s->dma_adc.count = 0;
+			s->dma_adc.nextIn = s->dma_adc.nextOut = 0;
+		}
+		return 0;
+
+	case SNDCTL_DSP_SPEED:
+		if (get_user(val, (int *)arg))
+			return -EFAULT;
+		if (val >= 0) {
+			if (file->f_mode & FMODE_READ) {
+				stop_adc(s);
+				set_adc_rate(s, val);
+				if ((ret = prog_dmabuf_adc(s)))
+					return ret;
+			}
+			if (file->f_mode & FMODE_WRITE) {
+				stop_dac(s);
+				set_dac_rate(s, val);
+				if ((ret = prog_dmabuf_dac(s)))
+					return ret;
+			}
+		}
+		return put_user((file->f_mode & FMODE_READ) ?
+				s->adcRate : s->dacRate, (int *)arg);
+
+	case SNDCTL_DSP_STEREO:
+		if (get_user(val, (int *)arg))
+			return -EFAULT;
+		if (file->f_mode & FMODE_READ) {
+			stop_adc(s);
+			if (val)
+				s->adcChannels = 2;
+			else
+				s->adcChannels = 1;
+			if ((ret = prog_dmabuf_adc(s)))
+				return ret;
+		}
+		if (file->f_mode & FMODE_WRITE) {
+			stop_dac(s);
+			if (val)
+				s->dacChannels = 2;
+			else
+				s->dacChannels = 1;
+			if ((ret = prog_dmabuf_dac(s)))
+				return ret;
+		}
+		return 0;
+
+	case SNDCTL_DSP_CHANNELS:
+		if (get_user(val, (int *)arg))
+			return -EFAULT;
+		if (val != 0) {
+			if ((val != 1) && (val != 2))
+				val = 2;
+
+			if (file->f_mode & FMODE_READ) {
+				stop_adc(s);
+				s->dacChannels = val;
+				if ((ret = prog_dmabuf_adc(s)))
+					return ret;
+			}
+			if (file->f_mode & FMODE_WRITE) {
+				stop_dac(s);
+				s->dacChannels = val;
+				if ((ret = prog_dmabuf_dac(s)))
+					return ret;
+			}
+		}
+		return put_user(val, (int *)arg);
+
+	case SNDCTL_DSP_GETFMTS:	/* Returns a mask */
+		return put_user(AFMT_S16_LE, (int *)arg);
+
+	case SNDCTL_DSP_SETFMT:	/* Selects ONE fmt */
+		if (get_user(val, (int *)arg))
+			return -EFAULT;
+		if (val != AFMT_QUERY) {
+			if (val != AFMT_S16_LE)
+				return -EINVAL;
+			if (file->f_mode & FMODE_READ) {
+				stop_adc(s);
+				if ((ret = prog_dmabuf_adc(s)))
+					return ret;
+			}
+			if (file->f_mode & FMODE_WRITE) {
+				stop_dac(s);
+				if ((ret = prog_dmabuf_dac(s)))
+					return ret;
+			}
+		} else {
+			val = AFMT_S16_LE;
+		}
+		return put_user(val, (int *)arg);
+
+	case SNDCTL_DSP_POST:
+		return 0;
+
+	case SNDCTL_DSP_GETTRIGGER:
+	case SNDCTL_DSP_SETTRIGGER:
+		/* NO trigger */
+		return -EINVAL;
+
+	case SNDCTL_DSP_GETOSPACE:
+		if (!(file->f_mode & FMODE_WRITE))
+			return -EINVAL;
+		abinfo.fragsize = s->dma_dac.fragSize << (s->dacChannels - 1);
+		spin_lock_irqsave(&s->lock, flags);
+		count = s->dma_dac.count;
+		spin_unlock_irqrestore(&s->lock, flags);
+		abinfo.bytes = (s->dma_dac.fragTotalSize - count) <<
+		    (s->dacChannels - 1);
+		abinfo.fragstotal = s->dma_dac.numFrag;
+		abinfo.fragments = abinfo.bytes >> s->dma_dac.fragShift >>
+		    (s->dacChannels - 1);
+		return copy_to_user((void *)arg, &abinfo,
+				    sizeof(abinfo)) ? -EFAULT : 0;
+
+	case SNDCTL_DSP_GETISPACE:
+		if (!(file->f_mode & FMODE_READ))
+			return -EINVAL;
+		abinfo.fragsize = s->dma_adc.fragSize << (s->adcChannels - 1);
+		spin_lock_irqsave(&s->lock, flags);
+		count = s->dma_adc.count;
+		spin_unlock_irqrestore(&s->lock, flags);
+		if (count < 0)
+			count = 0;
+		abinfo.bytes = count << (s->adcChannels - 1);
+		abinfo.fragstotal = s->dma_adc.numFrag;
+		abinfo.fragments = (abinfo.bytes >> s->dma_adc.fragShift) >>
+		    (s->adcChannels - 1);
+		return copy_to_user((void *)arg, &abinfo,
+				    sizeof(abinfo)) ? -EFAULT : 0;
+
+	case SNDCTL_DSP_NONBLOCK:
+		file->f_flags |= O_NONBLOCK;
+		return 0;
+
+	case SNDCTL_DSP_GETODELAY:
+		if (!(file->f_mode & FMODE_WRITE))
+			return -EINVAL;
+		spin_lock_irqsave(&s->lock, flags);
+		count = s->dma_dac.count;
+		spin_unlock_irqrestore(&s->lock, flags);
+		return put_user(count, (int *)arg);
+
+	case SNDCTL_DSP_GETIPTR:
+	case SNDCTL_DSP_GETOPTR:
+		/* we cannot get DMA ptr */
+		return -EINVAL;
+
+	case SNDCTL_DSP_GETBLKSIZE:
+		if (file->f_mode & FMODE_WRITE)
+			return put_user(s->dma_dac.
+					fragSize << (s->dacChannels - 1),
+					(int *)arg);
+		else
+			return put_user(s->dma_adc.
+					fragSize << (s->adcChannels - 1),
+					(int *)arg);
+
+	case SNDCTL_DSP_SETFRAGMENT:
+		/* we ignore fragment size request */
+		return 0;
+
+	case SNDCTL_DSP_SUBDIVIDE:
+		/* what is this for? [jsun] */
+		return 0;
+
+	case SOUND_PCM_READ_RATE:
+		return put_user((file->f_mode & FMODE_READ) ?
+				s->adcRate : s->dacRate, (int *)arg);
+
+	case SOUND_PCM_READ_CHANNELS:
+		if (file->f_mode & FMODE_READ)
+			return put_user(s->adcChannels, (int *)arg);
+		else
+			return put_user(s->dacChannels ? 2 : 1, (int *)arg);
+
+	case SOUND_PCM_READ_BITS:
+		return put_user(16, (int *)arg);
+
+	case SOUND_PCM_WRITE_FILTER:
+	case SNDCTL_DSP_SETSYNCRO:
+	case SOUND_PCM_READ_FILTER:
+		return -EINVAL;
+	}
+
+	return mixdev_ioctl(s->codec, cmd, arg);
+}
+
+static int vr5701_ac97_open(struct inode *inode, struct file *file)
+{
+	int minor = iminor(inode);
+	DECLARE_WAITQUEUE(wait, current);
+	unsigned long flags;
+	struct list_head *list;
+	struct vr5701_ac97_state *s;
+	int ret = 0;
+
+	nonseekable_open(inode, file);
+	for (list = devs.next;; list = list->next) {
+		if (list == &devs)
+			return -ENODEV;
+		s = list_entry(list, struct vr5701_ac97_state, devs);
+		if (!((s->dev_audio ^ minor) & ~0xf))
+			break;
+	}
+	file->private_data = s;
+
+	/* wait for device to become free */
+	down(&s->open_sem);
+	while (s->open_mode & file->f_mode) {
+
+		if (file->f_flags & O_NONBLOCK) {
+			up(&s->open_sem);
+			return -EBUSY;
+		}
+		add_wait_queue(&s->open_wait, &wait);
+		__set_current_state(TASK_INTERRUPTIBLE);
+		up(&s->open_sem);
+		schedule();
+		remove_wait_queue(&s->open_wait, &wait);
+		set_current_state(TASK_RUNNING);
+		if (signal_pending(current))
+			return -ERESTARTSYS;
+		down(&s->open_sem);
+	}
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	if (file->f_mode & FMODE_READ) {
+		/* set default settings */
+		set_adc_rate(s, 48000);
+		s->adcChannels = 2;
+
+		ret = prog_dmabuf_adc(s);
+		if (ret)
+			goto bailout;
+	}
+	if (file->f_mode & FMODE_WRITE) {
+		/* set default settings */
+		set_dac_rate(s, 48000);
+		s->dacChannels = 2;
+
+		ret = prog_dmabuf_dac(s);
+		if (ret)
+			goto bailout;
+	}
+
+	s->open_mode |= file->f_mode & (FMODE_READ | FMODE_WRITE);
+
+      bailout:
+	spin_unlock_irqrestore(&s->lock, flags);
+
+	up(&s->open_sem);
+	return ret;
+}
+
+static int vr5701_ac97_release(struct inode *inode, struct file *file)
+{
+	struct vr5701_ac97_state *s =
+	    (struct vr5701_ac97_state *)file->private_data;
+
+	lock_kernel();
+	if (file->f_mode & FMODE_WRITE)
+		drain_dac(s, file->f_flags & O_NONBLOCK);
+	down(&s->open_sem);
+	if (file->f_mode & FMODE_WRITE) {
+		stop_dac(s);
+		dealloc_dmabuf(s, &s->dma_dac);
+	}
+	if (file->f_mode & FMODE_READ) {
+		stop_adc(s);
+		dealloc_dmabuf(s, &s->dma_adc);
+	}
+	s->open_mode &= (~file->f_mode) & (FMODE_READ | FMODE_WRITE);
+	up(&s->open_sem);
+	wake_up(&s->open_wait);
+	unlock_kernel();
+	return 0;
+}
+
+static struct file_operations vr5701_ac97_audio_fops = {
+	.owner = THIS_MODULE,
+	.llseek = no_llseek,
+	.read = vr5701_ac97_read,
+	.write = vr5701_ac97_write,
+	.poll = vr5701_ac97_poll,
+	.ioctl = vr5701_ac97_ioctl,
+	.open = vr5701_ac97_open,
+	.release = vr5701_ac97_release,
+};
+
+/*
+ * for debugging purposes, we'll create a proc device that dumps the
+ * CODEC chipstate
+ */
+
+#ifdef vr5701_AC97_DEBUG
+
+struct {
+	const char *regname;
+	unsigned regaddr;
+} vr5701_ac97_regs[] = {
+	{
+	"vr5701_INT_STATUS", vr5701_INT_STATUS}, {
+	"vr5701_CODEC_WR", vr5701_CODEC_WR}, {
+	"vr5701_CODEC_RD", vr5701_CODEC_RD}, {
+	"vr5701_CTRL", vr5701_CTRL}, {
+	"vr5701_ACLINK_CTRL", vr5701_ACLINK_CTRL}, {
+	"vr5701_INT_MASK", vr5701_INT_MASK}, {
+	"vr5701_DAC1_CTRL", vr5701_DAC1_CTRL}, {
+	"vr5701_DAC1L", vr5701_DAC1L}, {
+	"vr5701_DAC1_BADDR", vr5701_DAC1_BADDR}, {
+	"vr5701_DAC2_CTRL", vr5701_DAC2_CTRL}, {
+	"vr5701_DAC2L", vr5701_DAC2L}, {
+	"vr5701_DAC2_BADDR", vr5701_DAC2_BADDR}, {
+	"vr5701_DAC3_CTRL", vr5701_DAC3_CTRL}, {
+	"vr5701_DAC3L", vr5701_DAC3L}, {
+	"vr5701_DAC3_BADDR", vr5701_DAC3_BADDR}, {
+	"vr5701_ADC1_CTRL", vr5701_ADC1_CTRL}, {
+	"vr5701_ADC1L", vr5701_ADC1L}, {
+	"vr5701_ADC1_BADDR", vr5701_ADC1_BADDR}, {
+	"vr5701_ADC2_CTRL", vr5701_ADC2_CTRL}, {
+	"vr5701_ADC2L", vr5701_ADC2L}, {
+	"vr5701_ADC2_BADDR", vr5701_ADC2_BADDR}, {
+	"vr5701_ADC3_CTRL", vr5701_ADC3_CTRL}, {
+	"vr5701_ADC3L", vr5701_ADC3L}, {
+	"vr5701_ADC3_BADDR", vr5701_ADC3_BADDR}, {
+	NULL, 0x0}
+};
+
+static int proc_vr5701_ac97_dump(char *buf, char **start, off_t fpos,
+				 int length, int *eof, void *data)
+{
+	struct vr5701_ac97_state *s;
+	int cnt, len = 0;
+
+	if (list_empty(&devs))
+		return 0;
+	s = list_entry(devs.next, struct vr5701_ac97_state, devs);
+
+	/* print out header */
+	len += sprintf(buf + len, "\n\t\tvr5701 Audio Debug\n\n");
+
+	len += sprintf(buf + len, "NEC vr5701 Audio Controller registers\n");
+	len += sprintf(buf + len, "---------------------------------\n");
+	for (cnt = 0; vr5701_ac97_regs[cnt].regname != NULL; cnt++) {
+		len += sprintf(buf + len, "%-20s = %08x\n",
+			       vr5701_ac97_regs[cnt].regname,
+			       inl(s->io + vr5701_ac97_regs[cnt].regaddr));
+	}
+
+	/* print out driver state */
+	len += sprintf(buf + len, "NEC vr5701 Audio driver states\n");
+	len += sprintf(buf + len, "---------------------------------\n");
+	len += sprintf(buf + len, "dacChannels  = %d\n", s->dacChannels);
+	len += sprintf(buf + len, "adcChannels  = %d\n", s->adcChannels);
+	len += sprintf(buf + len, "dacRate  = %d\n", s->dacRate);
+	len += sprintf(buf + len, "adcRate  = %d\n", s->adcRate);
+
+	len += sprintf(buf + len, "dma_dac is %s ready\n",
+		       s->dma_dac.ready ? "" : "not");
+	if (s->dma_dac.ready) {
+		len += sprintf(buf + len, "dma_dac is %s stopped.\n",
+			       s->dma_dac.stopped ? "" : "not");
+		len += sprintf(buf + len, "dma_dac.fragSize = %x\n",
+			       s->dma_dac.fragSize);
+		len += sprintf(buf + len, "dma_dac.fragShift = %x\n",
+			       s->dma_dac.fragShift);
+		len += sprintf(buf + len, "dma_dac.numFrag = %x\n",
+			       s->dma_dac.numFrag);
+		len += sprintf(buf + len, "dma_dac.fragTotalSize = %x\n",
+			       s->dma_dac.fragTotalSize);
+		len += sprintf(buf + len, "dma_dac.nextIn = %x\n",
+			       s->dma_dac.nextIn);
+		len += sprintf(buf + len, "dma_dac.nextOut = %x\n",
+			       s->dma_dac.nextOut);
+		len += sprintf(buf + len, "dma_dac.count = %x\n",
+			       s->dma_dac.count);
+	}
+
+	len += sprintf(buf + len, "dma_adc is %s ready\n",
+		       s->dma_adc.ready ? "" : "not");
+	if (s->dma_adc.ready) {
+		len += sprintf(buf + len, "dma_adc is %s stopped.\n",
+			       s->dma_adc.stopped ? "" : "not");
+		len += sprintf(buf + len, "dma_adc.fragSize = %x\n",
+			       s->dma_adc.fragSize);
+		len += sprintf(buf + len, "dma_adc.fragShift = %x\n",
+			       s->dma_adc.fragShift);
+		len += sprintf(buf + len, "dma_adc.numFrag = %x\n",
+			       s->dma_adc.numFrag);
+		len += sprintf(buf + len, "dma_adc.fragTotalSize = %x\n",
+			       s->dma_adc.fragTotalSize);
+		len += sprintf(buf + len, "dma_adc.nextIn = %x\n",
+			       s->dma_adc.nextIn);
+		len += sprintf(buf + len, "dma_adc.nextOut = %x\n",
+			       s->dma_adc.nextOut);
+		len += sprintf(buf + len, "dma_adc.count = %x\n",
+			       s->dma_adc.count);
+	}
+
+	/* print out CODEC state */
+	len += sprintf(buf + len, "\nAC97 CODEC registers\n");
+	len += sprintf(buf + len, "----------------------\n");
+	for (cnt = 0; cnt <= 0x7e; cnt = cnt + 2)
+		len += sprintf(buf + len, "reg %02x = %04x\n",
+			       cnt, rdcodec(s->codec, cnt));
+
+	if (fpos >= len) {
+		*start = buf;
+		*eof = 1;
+		return 0;
+	}
+	*start = buf + fpos;
+	if ((len -= fpos) > length)
+		return length;
+	*eof = 1;
+	return len;
+
+}
+#endif				/* vr5701_AC97_DEBUG */
+
+static unsigned int devindex;
+
+MODULE_AUTHOR("Sergey Podstavin");
+MODULE_DESCRIPTION("NEC Vr5701 audio (AC97) Driver");
+MODULE_LICENSE("GPL");
+
+static int __devinit vr5701_ac97_probe(struct pci_dev *pcidev,
+				       const struct pci_device_id *pciid)
+{
+	struct vr5701_ac97_state *s;
+#ifdef vr5701_AC97_DEBUG
+	char proc_str[80];
+#endif
+
+	if (pcidev->irq == 0)
+		return -1;
+
+	if (!(s = kmalloc(sizeof(struct vr5701_ac97_state), GFP_KERNEL))) {
+		printk(KERN_ERR PFX "alloc of device struct failed\n");
+		return -1;
+	}
+	memset(s, 0, sizeof(struct vr5701_ac97_state));
+
+	init_waitqueue_head(&s->dma_adc.wait);
+	init_waitqueue_head(&s->dma_dac.wait);
+	init_waitqueue_head(&s->open_wait);
+	init_MUTEX(&s->open_sem);
+	spin_lock_init(&s->lock);
+
+	s->dev = pcidev;
+	s->io = pci_resource_start(pcidev, 0);
+	s->irq = pcidev->irq;
+
+	s->codec = ac97_alloc_codec();
+
+	s->codec->private_data = s;
+	s->codec->id = 0;
+	s->codec->codec_read = rdcodec;
+	s->codec->codec_write = wrcodec;
+	s->codec->codec_wait = waitcodec;
+
+	/* setting some other default values such as
+	 * adcChannels, adcRate is done in open() so that
+	 * no persistent state across file opens.
+	 */
+
+	if (!request_region(s->io, pci_resource_len(pcidev, 0),
+			    vr5701_AC97_MODULE_NAME)) {
+		printk(KERN_ERR PFX "io ports %#lx->%#lx in use\n",
+		       s->io, s->io + pci_resource_len(pcidev, 0) - 1);
+		goto err_region;
+	}
+	if (request_irq(s->irq, vr5701_ac97_interrupt, SA_INTERRUPT,
+			vr5701_AC97_MODULE_NAME, s)) {
+		printk(KERN_ERR PFX "irq %u in use\n", s->irq);
+		goto err_irq;
+	}
+
+	printk(KERN_INFO PFX "IO at %#lx, IRQ %d\n", s->io, s->irq);
+
+	/* register devices */
+	if ((s->dev_audio =
+	     register_sound_dsp(&vr5701_ac97_audio_fops, -1)) < 0)
+		goto err_dev1;
+	if ((s->codec->dev_mixer =
+	     register_sound_mixer(&vr5701_ac97_mixer_fops, -1)) < 0)
+		goto err_dev2;
+
+#ifdef vr5701_AC97_DEBUG
+	/* initialize the debug proc device */
+	s->ps = create_proc_read_entry(vr5701_AC97_MODULE_NAME, 0, NULL,
+				       proc_vr5701_ac97_dump, NULL);
+#endif				/* vr5701_AC97_DEBUG */
+
+	/* enable pci io and bus mastering */
+	if (pci_enable_device(pcidev))
+		goto err_dev3;
+	pci_set_master(pcidev);
+
+	/* cold reset the AC97 */
+	outl(vr5701_ACLINK_CTRL_RST_ON | vr5701_ACLINK_CTRL_RST_TIME,
+	     s->io + vr5701_ACLINK_CTRL);
+	while (inl(s->io + vr5701_ACLINK_CTRL) & vr5701_ACLINK_CTRL_RST_ON) ;
+
+	/* codec init */
+	if (!ac97_probe_codec(s->codec))
+		goto err_dev3;
+
+#ifdef vr5701_AC97_DEBUG
+	sprintf(proc_str, "driver/%s/%d/ac97",
+		vr5701_AC97_MODULE_NAME, s->codec->id);
+	s->ac97_ps = create_proc_read_entry(proc_str, 0, NULL,
+					    ac97_read_proc, s->codec);
+	/* TODO : why this proc file does not show up? */
+#endif
+
+	/* Try to enable variable rate audio mode. */
+	wrcodec(s->codec, AC97_EXTENDED_STATUS,
+		rdcodec(s->codec, AC97_EXTENDED_STATUS) | AC97_EXTSTAT_VRA);
+	/* Did we enable it? */
+	if (rdcodec(s->codec, AC97_EXTENDED_STATUS) & AC97_EXTSTAT_VRA)
+		s->extended_status |= AC97_EXTSTAT_VRA;
+	else {
+		s->dacRate = 48000;
+		printk(KERN_INFO PFX "VRA mode not enabled; rate fixed at %d.",
+		       s->dacRate);
+	}
+
+	/* let us get the default volumne louder */
+	wrcodec(s->codec, 0x2, 0x1010);	/* master volume, middle */
+	wrcodec(s->codec, 0xc, 0x10);	/* phone volume, middle */
+	wrcodec(s->codec, 0x10, 0x8000);	/* line-in 2 line-out disable */
+	wrcodec(s->codec, 0x18, 0x0707);	/* PCM out (line out) middle */
+
+	/* by default we select line in the input */
+	wrcodec(s->codec, 0xe, 0x10);	/* misc volume, middle */
+	wrcodec(s->codec, 0x1a, 0x0000);	/* default line is Line_mic */
+	/*	wrcodec(s->codec, 0x1a, 0x0404); *//* default line is Line_in */
+	wrcodec(s->codec, 0x1c, 0x0f0f);
+	wrcodec(s->codec, 0x1e, 0x07);
+
+	/* enable the master interrupt but disable all others */
+	outl(vr5701_INT_MASK_NMASK, s->io + vr5701_INT_MASK);
+
+	/* store it in the driver field */
+	pci_set_drvdata(pcidev, s);
+	pcidev->dma_mask = 0xffffffff;
+	/* put it into driver list */
+	list_add_tail(&s->devs, &devs);
+	/* increment devindex */
+	if (devindex < NR_DEVICE - 1)
+		devindex++;
+	return 0;
+
+      err_dev3:
+	unregister_sound_mixer(s->codec->dev_mixer);
+      err_dev2:
+	unregister_sound_dsp(s->dev_audio);
+      err_dev1:
+	printk(KERN_ERR PFX "cannot register misc device\n");
+	free_irq(s->irq, s);
+
+      err_irq:
+	release_region(s->io, pci_resource_len(pcidev, 0));
+      err_region:
+	ac97_release_codec(s->codec);
+	kfree(s);
+	return -1;
+}
+
+static void __devexit vr5701_ac97_remove(struct pci_dev *dev)
+{
+	struct vr5701_ac97_state *s = pci_get_drvdata(dev);
+
+	if (!s)
+		return;
+	list_del(&s->devs);
+
+#ifdef vr5701_AC97_DEBUG
+	if (s->ps)
+		remove_proc_entry(vr5701_AC97_MODULE_NAME, NULL);
+#endif				/* vr5701_AC97_DEBUG */
+
+	synchronize_irq();
+	free_irq(s->irq, s);
+	release_region(s->io, pci_resource_len(dev, 0));
+	unregister_sound_dsp(s->dev_audio);
+	unregister_sound_mixer(s->codec->dev_mixer);
+	ac97_release_codec(s->codec);
+	kfree(s);
+	pci_set_drvdata(dev, NULL);
+}
+
+static struct pci_device_id id_table[] = {
+	{PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_VRC5477_AC97,
+	 PCI_ANY_ID, PCI_ANY_ID, 0, 0},
+	{0,}
+};
+
+MODULE_DEVICE_TABLE(pci, id_table);
+
+static struct pci_driver vr5701_ac97_driver = {
+	.name = vr5701_AC97_MODULE_NAME,
+	.id_table = id_table,
+	.probe = vr5701_ac97_probe,
+	.remove = __devexit_p(vr5701_ac97_remove)
+};
+
+static int __init init_vr5701_ac97(void)
+{
+	printk(KERN_INFO "Vr5701 AC97 driver: time " __TIME__ " " __DATE__
+	       " by Sergey Podstavin\n");
+	return pci_module_init(&vr5701_ac97_driver);
+}
+
+static void __exit cleanup_vr5701_ac97(void)
+{
+	printk(KERN_INFO PFX "unloading\n");
+	pci_unregister_driver(&vr5701_ac97_driver);
+}
+
+module_init(init_vr5701_ac97);
+module_exit(cleanup_vr5701_ac97);
diff -Naurp --exclude=CVS linux_mips_save/sound/oss/nec_vr5701_sg2.h linux_mips/sound/oss/nec_vr5701_sg2.h
--- linux_mips_save/sound/oss/nec_vr5701_sg2.h	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/sound/oss/nec_vr5701_sg2.h	2005-05-31 15:40:52.000000000 +0400
@@ -0,0 +1,530 @@
+/*
+ * sound/oss/nec_vr5701_sg2.h
+ *
+ * An AC97 sounf driver for NEC VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/kernel.h>
+#include <linux/ioport.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/sound.h>
+#include <linux/slab.h>
+#include <linux/soundcard.h>
+#include <linux/pci.h>
+#include <linux/init.h>
+#include <linux/poll.h>
+#include <linux/bitops.h>
+#include <linux/proc_fs.h>
+#include <linux/spinlock.h>
+#include <linux/smp_lock.h>
+#include <linux/ac97_codec.h>
+#include <linux/interrupt.h>
+#include <asm/hardirq.h>
+#include <asm/io.h>
+#include <asm/dma.h>
+#include <asm/uaccess.h>
+
+#define         vr5701_INT_CLR         0x0
+#define         vr5701_INT_STATUS	0x0
+#define         vr5701_CODEC_WR        0x4
+#define         vr5701_CODEC_RD        0x8
+#define         vr5701_CTRL            0x18
+#define         vr5701_ACLINK_CTRL     0x1c
+#define         vr5701_INT_MASK        0x24
+
+#define		vr5701_DAC1_CTRL	0x30
+#define		vr5701_DAC1L		0x34
+#define		vr5701_DAC1_BADDR	0x38
+#define		vr5701_DAC2_CTRL	0x3c
+#define		vr5701_DAC2L		0x40
+#define		vr5701_DAC2_BADDR	0x44
+#define		vr5701_DAC3_CTRL	0x48
+#define		vr5701_DAC3L		0x4c
+#define		vr5701_DAC3_BADDR	0x50
+
+#define		vr5701_ADC1_CTRL	0x54
+#define		vr5701_ADC1L		0x58
+#define		vr5701_ADC1_BADDR	0x5c
+#define		vr5701_ADC2_CTRL	0x60
+#define		vr5701_ADC2L		0x64
+#define		vr5701_ADC2_BADDR	0x68
+#define		vr5701_ADC3_CTRL	0x6c
+#define		vr5701_ADC3L		0x70
+#define		vr5701_ADC3_BADDR	0x74
+
+#define		vr5701_CODEC_WR_RWC	(1 << 23)
+
+#define		vr5701_CODEC_RD_RRDYA	(1 << 31)
+#define		vr5701_CODEC_RD_RRDYD	(1 << 30)
+
+#define		vr5701_ACLINK_CTRL_RST_ON	(1 << 15)
+#define		vr5701_ACLINK_CTRL_RST_TIME	0x7f
+#define		vr5701_ACLINK_CTRL_SYNC_ON	(1 << 30)
+#define		vr5701_ACLINK_CTRL_CK_STOP_ON	(1 << 31)
+
+#define		vr5701_CTRL_DAC2ENB		(1 << 15)
+#define		vr5701_CTRL_ADC2ENB		(1 << 14)
+#define		vr5701_CTRL_DAC1ENB		(1 << 13)
+#define		vr5701_CTRL_ADC1ENB		(1 << 12)
+
+#define		vr5701_INT_MASK_NMASK		(1 << 31)
+#define		vr5701_INT_MASK_DAC1END	(1 << 5)
+#define		vr5701_INT_MASK_DAC2END	(1 << 4)
+#define		vr5701_INT_MASK_DAC3END	(1 << 3)
+#define		vr5701_INT_MASK_ADC1END	(1 << 2)
+#define		vr5701_INT_MASK_ADC2END	(1 << 1)
+#define		vr5701_INT_MASK_ADC3END	(1 << 0)
+
+#define		vr5701_DMA_ACTIVATION		(1 << 31)
+#define		vr5701_DMA_WIP			(1 << 30)
+
+#define vr5701_AC97_MODULE_NAME "NEC_vr5701_audio"
+#define PFX vr5701_AC97_MODULE_NAME ": "
+#define	WORK_BUF_SIZE	2048
+
+#define DMABUF_DEFAULTORDER (16-PAGE_SHIFT)
+#define DMABUF_MINORDER 1
+
+/* maximum number of devices; only used for command line params */
+#define NR_DEVICE 5
+/* -------------------debug macros -------------------------------------- */
+#undef vr5701_AC97_DEBUG
+
+#undef vr5701_AC97_VERBOSE_DEBUG
+
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+#define vr5701_AC97_DEBUG
+#endif
+
+#if defined(vr5701_AC97_DEBUG)
+#define ASSERT(x)  if (!(x)) { \
+	panic("assertion failed at %s:%d: %s\n", __FILE__, __LINE__, #x); }
+#else
+#define	ASSERT(x)
+#endif				/* vr5701_AC97_DEBUG */
+
+static inline unsigned ld2(unsigned int x)
+{
+	unsigned r = 0;
+
+	if (x >= 0x10000) {
+		x >>= 16;
+		r += 16;
+	}
+	if (x >= 0x100) {
+		x >>= 8;
+		r += 8;
+	}
+	if (x >= 0x10) {
+		x >>= 4;
+		r += 4;
+	}
+	if (x >= 4) {
+		x >>= 2;
+		r += 2;
+	}
+	if (x >= 2)
+		r++;
+	return r;
+}
+
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+static u16 inTicket;		/* check sync between intr & write */
+static u16 outTicket;
+#endif
+
+#undef OSS_DOCUMENTED_MIXER_SEMANTICS
+
+static const unsigned sample_shift[] = { 0, 1, 1, 2 };
+
+struct vr5701_ac97_state {
+	/* list of vr5701_ac97 devices */
+	struct list_head devs;
+
+	/* the corresponding pci_dev structure */
+	struct pci_dev *dev;
+
+	/* soundcore stuff */
+	int dev_audio;
+
+	/* hardware resources */
+	unsigned long io;
+	unsigned int irq;
+
+#ifdef vr5701_AC97_DEBUG
+	/* debug /proc entry */
+	struct proc_dir_entry *ps;
+	struct proc_dir_entry *ac97_ps;
+#endif				/* vr5701_AC97_DEBUG */
+
+	struct ac97_codec *codec;
+
+	unsigned dacChannels, adcChannels;
+	unsigned short dacRate, adcRate;
+	unsigned short extended_status;
+
+	spinlock_t lock;
+	struct semaphore open_sem;
+	mode_t open_mode;
+	wait_queue_head_t open_wait;
+
+	struct dmabuf {
+		void *lbuf, *rbuf;
+		dma_addr_t lbufDma, rbufDma;
+		unsigned bufOrder;
+		unsigned numFrag;
+		unsigned fragShift;
+		unsigned fragSize;	/* redundant */
+		unsigned fragTotalSize;	/* = numFrag * fragSize(real)  */
+		unsigned nextIn;
+		unsigned nextOut;
+		int count;
+		unsigned error;	/* over/underrun */
+		wait_queue_head_t wait;
+		/* OSS stuff */
+		unsigned stopped:1;
+		unsigned ready:1;
+	} dma_dac, dma_adc;
+
+	struct {
+		u16 lchannel;
+		u16 rchannel;
+	} workBuf[WORK_BUF_SIZE / 4];
+};
+static inline void stop_dac(struct vr5701_ac97_state *s)
+{
+	struct dmabuf *db = &s->dma_dac;
+	unsigned long flags;
+	u32 temp;
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	if (db->stopped) {
+		spin_unlock_irqrestore(&s->lock, flags);
+		return;
+	}
+
+	/* deactivate the dma */
+	outl(0, s->io + vr5701_DAC1_CTRL);
+	outl(0, s->io + vr5701_DAC2_CTRL);
+
+	/* wait for DAM completely stop */
+	while (inl(s->io + vr5701_DAC1_CTRL) & vr5701_DMA_WIP) ;
+	while (inl(s->io + vr5701_DAC2_CTRL) & vr5701_DMA_WIP) ;
+
+	/* disable dac slots in aclink */
+	temp = inl(s->io + vr5701_CTRL);
+	temp &= ~(vr5701_CTRL_DAC1ENB | vr5701_CTRL_DAC2ENB);
+	outl(temp, s->io + vr5701_CTRL);
+
+	/* disable interrupts */
+	temp = inl(s->io + vr5701_INT_MASK);
+	temp &= ~(vr5701_INT_MASK_DAC1END | vr5701_INT_MASK_DAC2END);
+	outl(temp, s->io + vr5701_INT_MASK);
+
+	/* clear pending ones */
+	outl(vr5701_INT_MASK_DAC1END | vr5701_INT_MASK_DAC2END,
+	     s->io + vr5701_INT_CLR);
+
+	db->stopped = 1;
+
+	spin_unlock_irqrestore(&s->lock, flags);
+}
+
+static inline void stop_adc(struct vr5701_ac97_state *s)
+{
+	struct dmabuf *db = &s->dma_adc;
+	unsigned long flags;
+	u32 temp;
+
+	spin_lock_irqsave(&s->lock, flags);
+
+	if (db->stopped) {
+		spin_unlock_irqrestore(&s->lock, flags);
+		return;
+	}
+
+	/* deactivate the dma */
+	outl(0, s->io + vr5701_ADC1_CTRL);
+	outl(0, s->io + vr5701_ADC2_CTRL);
+
+	/* disable adc slots in aclink */
+	temp = inl(s->io + vr5701_CTRL);
+	temp &= ~(vr5701_CTRL_ADC1ENB | vr5701_CTRL_ADC2ENB);
+	outl(temp, s->io + vr5701_CTRL);
+
+	/* disable interrupts */
+	temp = inl(s->io + vr5701_INT_MASK);
+	temp &= ~(vr5701_INT_MASK_ADC1END | vr5701_INT_MASK_ADC2END);
+	outl(temp, s->io + vr5701_INT_MASK);
+
+	/* clear pending ones */
+	outl(vr5701_INT_MASK_ADC1END | vr5701_INT_MASK_ADC2END,
+	     s->io + vr5701_INT_CLR);
+
+	db->stopped = 1;
+
+	spin_unlock_irqrestore(&s->lock, flags);
+}
+
+static inline void dealloc_dmabuf(struct vr5701_ac97_state *s,
+				  struct dmabuf *db)
+{
+	if (db->lbuf) {
+		ASSERT(db->rbuf);
+		pci_free_consistent(s->dev, PAGE_SIZE << db->bufOrder,
+				    db->lbuf, db->lbufDma);
+		pci_free_consistent(s->dev, PAGE_SIZE << db->bufOrder,
+				    db->rbuf, db->rbufDma);
+		db->lbuf = db->rbuf = NULL;
+	}
+	db->nextIn = db->nextOut = 0;
+	db->ready = 0;
+}
+
+static inline int prog_dmabuf_adc(struct vr5701_ac97_state *s)
+{
+	stop_adc(s);
+	return prog_dmabuf(s, &s->dma_adc, s->adcRate);
+}
+
+static inline int prog_dmabuf_dac(struct vr5701_ac97_state *s)
+{
+	stop_dac(s);
+	return prog_dmabuf(s, &s->dma_dac, s->dacRate);
+}
+
+static inline void vr5701_ac97_adc_interrupt(struct vr5701_ac97_state *s)
+{
+	struct dmabuf *adc = &s->dma_adc;
+	unsigned temp;
+
+	/* we need two frags avaiable because one is already being used
+	 * and the other will be used when next interrupt happens.
+	 */
+	if (adc->count >= adc->fragTotalSize - adc->fragSize) {
+		stop_adc(s);
+		adc->error++;
+		printk(KERN_INFO PFX "adc overrun\n");
+		return;
+	}
+
+	/* set the base addr for next DMA transfer */
+	temp = adc->nextIn + 2 * adc->fragSize;
+	if (temp >= adc->fragTotalSize) {
+		ASSERT((temp == adc->fragTotalSize) ||
+		       (temp == adc->fragTotalSize + adc->fragSize));
+		temp -= adc->fragTotalSize;
+	}
+	outl(adc->lbufDma + temp, s->io + vr5701_ADC1_BADDR);
+	outl(adc->rbufDma + temp, s->io + vr5701_ADC2_BADDR);
+
+	/* adjust nextIn */
+	adc->nextIn += adc->fragSize;
+	if (adc->nextIn >= adc->fragTotalSize) {
+		ASSERT(adc->nextIn == adc->fragTotalSize);
+		adc->nextIn = 0;
+	}
+
+	/* adjust count */
+	adc->count += adc->fragSize;
+
+	/* wake up anybody listening */
+	if (waitqueue_active(&adc->wait)) {
+		wake_up_interruptible(&adc->wait);
+	}
+}
+
+static inline void vr5701_ac97_dac_interrupt(struct vr5701_ac97_state *s)
+{
+	struct dmabuf *dac = &s->dma_dac;
+	unsigned temp;
+
+	/* let us set for next next DMA transfer */
+	temp = dac->nextOut + dac->fragSize * 2;
+	if (temp >= dac->fragTotalSize) {
+		ASSERT((temp == dac->fragTotalSize) ||
+		       (temp == dac->fragTotalSize + dac->fragSize));
+		temp -= dac->fragTotalSize;
+	}
+	outl(dac->lbufDma + temp, s->io + vr5701_DAC1_BADDR);
+	if (s->dacChannels == 1) {
+		outl(dac->lbufDma + temp, s->io + vr5701_DAC2_BADDR);
+	} else {
+		outl(dac->rbufDma + temp, s->io + vr5701_DAC2_BADDR);
+	}
+
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+	if (*(u16 *) (dac->lbuf + dac->nextOut) != outTicket) {
+		printk(KERN_ERR "assert fail: - %d vs %d\n",
+		       *(u16 *) (dac->lbuf + dac->nextOut), outTicket);
+		ASSERT(1 == 0);
+	}
+#endif
+
+	/* adjust nextOut pointer */
+	dac->nextOut += dac->fragSize;
+	if (dac->nextOut >= dac->fragTotalSize) {
+		ASSERT(dac->nextOut == dac->fragTotalSize);
+		dac->nextOut = 0;
+	}
+
+	/* adjust count */
+	dac->count -= dac->fragSize;
+	if (dac->count <= 0) {
+		/* buffer under run */
+		dac->count = 0;
+		dac->nextIn = dac->nextOut;
+		stop_dac(s);
+	}
+#if defined(vr5701_AC97_VERBOSE_DEBUG)
+	if (dac->count) {
+		outTicket++;
+		ASSERT(*(u16 *) (dac->lbuf + dac->nextOut) == outTicket);
+	}
+#endif
+
+	/* we cannot have both under run and someone is waiting on us */
+	ASSERT(!(waitqueue_active(&dac->wait) && (dac->count <= 0)));
+
+	/* wake up anybody listening */
+	if (waitqueue_active(&dac->wait))
+		wake_up_interruptible(&dac->wait);
+}
+
+static inline int
+copy_two_channel_adc_to_user(struct vr5701_ac97_state *s,
+			     char *buffer, int copyCount)
+{
+	struct dmabuf *db = &s->dma_adc;
+	int bufStart = db->nextOut;
+	for (; copyCount > 0;) {
+		int i;
+		int count = copyCount;
+		if (count > WORK_BUF_SIZE / 2)
+			count = WORK_BUF_SIZE / 2;
+		for (i = 0; i < count / 2; i++) {
+			s->workBuf[i].lchannel =
+			    *(u16 *) (db->lbuf + bufStart + i * 2);
+			s->workBuf[i].rchannel =
+			    *(u16 *) (db->rbuf + bufStart + i * 2);
+		}
+		if (copy_to_user(buffer, s->workBuf, count * 2)) {
+			return -1;
+		}
+
+		copyCount -= count;
+		bufStart += count;
+		ASSERT(bufStart <= db->fragTotalSize);
+		buffer += count * 2;
+	}
+	return 0;
+}
+
+/* return the total bytes that is copied */
+static inline int
+copy_adc_to_user(struct vr5701_ac97_state *s,
+		 char *buffer, size_t count, int avail)
+{
+	struct dmabuf *db = &s->dma_adc;
+	int copyCount = 0;
+	int copyFragCount = 0;
+	int totalCopyCount = 0;
+	int totalCopyFragCount = 0;
+	unsigned long flags;
+
+	/* adjust count to signel channel byte count */
+	count >>= s->adcChannels - 1;
+
+	/* we may have to "copy" twice as ring buffer wraps around */
+	for (; (avail > 0) && (count > 0);) {
+		/* determine max possible copy count for single channel */
+		copyCount = count;
+		if (copyCount > avail) {
+			copyCount = avail;
+		}
+		if (copyCount + db->nextOut > db->fragTotalSize) {
+			copyCount = db->fragTotalSize - db->nextOut;
+			ASSERT((copyCount % db->fragSize) == 0);
+		}
+
+		copyFragCount = (copyCount - 1) >> db->fragShift;
+		copyFragCount = (copyFragCount + 1) << db->fragShift;
+		ASSERT(copyFragCount >= copyCount);
+
+		/* we copy differently based on adc channels */
+		if (s->adcChannels == 1) {
+			if (copy_to_user(buffer,
+					 db->lbuf + db->nextOut, copyCount))
+				return -1;
+		} else {
+			/* *sigh* we have to mix two streams into one  */
+			if (copy_two_channel_adc_to_user(s, buffer, copyCount))
+				return -1;
+		}
+
+		count -= copyCount;
+		totalCopyCount += copyCount;
+		avail -= copyFragCount;
+		totalCopyFragCount += copyFragCount;
+
+		buffer += copyCount << (s->adcChannels - 1);
+
+		db->nextOut += copyFragCount;
+		if (db->nextOut >= db->fragTotalSize) {
+			ASSERT(db->nextOut == db->fragTotalSize);
+			db->nextOut = 0;
+		}
+
+		ASSERT((copyFragCount % db->fragSize) == 0);
+		ASSERT((count == 0) || (copyCount == copyFragCount));
+	}
+
+	spin_lock_irqsave(&s->lock, flags);
+	db->count -= totalCopyFragCount;
+	spin_unlock_irqrestore(&s->lock, flags);
+
+	return totalCopyCount << (s->adcChannels - 1);
+}
+
+static inline int
+copy_two_channel_dac_from_user(struct vr5701_ac97_state *s,
+			       const char *buffer, int copyCount)
+{
+	struct dmabuf *db = &s->dma_dac;
+	int bufStart = db->nextIn;
+
+	ASSERT(db->ready);
+
+	for (; copyCount > 0;) {
+		int i;
+		int count = copyCount;
+		if (count > WORK_BUF_SIZE / 2)
+			count = WORK_BUF_SIZE / 2;
+		if (copy_from_user(s->workBuf, buffer, count * 2)) {
+			return -1;
+		}
+		for (i = 0; i < count / 2; i++) {
+			*(u16 *) (db->lbuf + bufStart + i * 2) =
+			    s->workBuf[i].lchannel;
+			*(u16 *) (db->rbuf + bufStart + i * 2) =
+			    s->workBuf[i].rchannel;
+		}
+
+		copyCount -= count;
+		bufStart += count;
+		ASSERT(bufStart <= db->fragTotalSize);
+		buffer += count * 2;
+	}
+	return 0;
+
+}

--=-OPaFC3FnAr8zyaHKvnnd--


From spodstavin@ru.mvista.com Tue May 31 14:27:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 14:28:08 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:32655 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225784AbVEaN1r>; Tue, 31 May 2005 14:27:47 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4VDRXt04835;
	Tue, 31 May 2005 18:27:33 +0500
Subject: [PATCH] A video driver for Lynx3DM on NEC VR5701-SG2 Board.
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	adaplas@pol.net
Cc:	linux-mips <linux-mips@linux-mips.org>
Content-Type: multipart/mixed; boundary="=-GzVKVITUotwBchgfD2st"
Organization: MontaVista
Date:	Tue, 31 May 2005 17:27:51 +0400
Message-Id: <1117546071.5564.20.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8027
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Antonio!

Attached is a video driver for Lynx3DM SM722, Silicon Motion Inc. It was
designed for NEC VR5701-SG2 Board, MIPS-CPU Vr5701. Please review it.

Best wishes,
Sergey Podstavin.

--=-GzVKVITUotwBchgfD2st
Content-Disposition: attachment; filename=community_mips_nec_vr5701_video_lynx3dm.patch
Content-Type: text/x-patch; name=community_mips_nec_vr5701_video_lynx3dm.patch; charset=UTF-8
Content-Transfer-Encoding: 7bit

diff -Naurp --exclude=CVS linux_save/drivers/video/Kconfig linux_mips/drivers/video/Kconfig
--- linux_save/drivers/video/Kconfig	2005-05-19 16:08:32.000000000 +0400
+++ linux_mips/drivers/video/Kconfig	2005-05-31 17:00:36.000000000 +0400
@@ -1027,6 +1027,25 @@ config FB_ATY_GX
 	  is at
 	  <http://support.ati.com/products/pc/mach64/graphics_xpression.html>.
 
+config FB_SM
+	tristate "Silicon Motion SM722 support"
+	depends on FB && PCI
+	help
+	  SM722
+
+choice
+	prompt "Display size"
+	depends on FB_SM
+	default DISPLAY_640x480
+
+config DISPLAY_640x480
+	bool "640x480"
+
+config DISPLAY_1024x768
+	bool "1024x768"
+
+endchoice
+
 config FB_SAVAGE
 	tristate "S3 Savage support"
 	depends on FB && PCI && EXPERIMENTAL
diff -Naurp --exclude=CVS linux_save/drivers/video/Makefile linux_mips/drivers/video/Makefile
--- linux_save/drivers/video/Makefile	2005-05-19 16:08:32.000000000 +0400
+++ linux_mips/drivers/video/Makefile	2005-05-31 17:03:40.000000000 +0400
@@ -38,6 +38,7 @@ obj-$(CONFIG_FB_KYRO)             += kyr
 obj-$(CONFIG_FB_SAVAGE)		  += savage/
 obj-$(CONFIG_FB_GEODE)		  += geode/
 obj-$(CONFIG_FB_I810)             += vgastate.o
+obj-$(CONFIG_FB_SM)               += smi/ cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_RADEON_OLD)	  += radeonfb.o
 obj-$(CONFIG_FB_NEOMAGIC)         += neofb.o vgastate.o
 obj-$(CONFIG_FB_VIRGE)            += virgefb.o
diff -Naurp --exclude=CVS linux_save/drivers/video/smi/Makefile linux_mips/drivers/video/smi/Makefile
--- linux_save/drivers/video/smi/Makefile	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/video/smi/Makefile	2005-05-31 17:00:36.000000000 +0400
@@ -0,0 +1,9 @@
+#
+# Makefile for LynxEM+/EM4+(Silicon Motion Inc.) fb driver for VR5701-SG2
+# under Linux.
+#
+
+obj-$(CONFIG_FB_SM)	+= smfb.o
+
+smfb-objs	:= smi_base.o smi_hw.o 
+
diff -Naurp --exclude=CVS linux_save/drivers/video/smi/smi_base.c linux_mips/drivers/video/smi/smi_base.c
--- linux_save/drivers/video/smi/smi_base.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/video/smi/smi_base.c	2005-05-31 17:00:36.000000000 +0400
@@ -0,0 +1,532 @@
+/*
+ * drivers/video/smi/smi_base.c
+ *
+ * LynxEM+/EM4+(Silicon Motion Inc.) fb driver	for VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/selection.h>
+#include <linux/tty.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/console.h>
+#include "../console/fbcon.h"
+#include "smifb.h"
+#include "smi_hw.h"
+
+/*
+ * Card Identification
+ *
+ */
+static struct pci_device_id smifb_pci_tbl[] __devinitdata = {
+	{PCI_VENDOR_ID_SMI, PCI_DEVICE_ID_SMI_LYNX_EM_PLUS,
+	 PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},	/* Lynx EM+/EM4+ */
+	{PCI_VENDOR_ID_SMI, PCI_DEVICE_ID_SMI_LYNX_3DM,
+	 PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},	/* Lynx 3DM/3DM+/3DM4+ */
+	{0,}			/* terminate list */
+};
+
+MODULE_DEVICE_TABLE(pci, smifb_pci_tbl);
+
+/*
+ *
+ * global variables
+ *
+ */
+
+#ifdef CONFIG_DISPLAY_1024x768
+/* 1024x768, 16bpp, 60Hz */
+static struct fb_var_screeninfo smifb_default_var = {
+      xres:1024,
+      yres:768,
+      xres_virtual:1024,
+      yres_virtual:768,
+      xoffset:0,
+      yoffset:0,
+      bits_per_pixel:16,
+      grayscale:0,
+      red:{11, 5, 0},
+      green:{5, 6, 0},
+      blue:{0, 5, 0},
+      transp:{0, 0, 0},
+      nonstd:0,
+      activate:0,
+      height:-1,
+      width:-1,
+      accel_flags:0,
+      pixclock:39721,		/* D */
+      left_margin:138,
+      right_margin:24,
+      upper_margin:24,
+      lower_margin:4,
+      hsync_len:160,
+      vsync_len:6,
+      sync:0,
+      vmode:FB_VMODE_NONINTERLACED
+};
+#else
+/* 640x480, 16bpp, 60Hz */
+static struct fb_var_screeninfo smifb_default_var = {
+      xres:640,
+      yres:480,
+      xres_virtual:640,
+      yres_virtual:480,
+      xoffset:0,
+      yoffset:0,
+      bits_per_pixel:16,
+      grayscale:0,
+      red:{11, 5, 0},
+      green:{5, 6, 0},
+      blue:{0, 5, 0},
+      transp:{0, 0, 0},
+      nonstd:0,
+      activate:0,
+      height:-1,
+      width:-1,
+      accel_flags:0,
+      pixclock:39721,		/* D */
+      left_margin:82,
+      right_margin:16,
+      upper_margin:19,
+      lower_margin:1,
+      hsync_len:152,
+      vsync_len:4,
+      sync:0,
+      vmode:FB_VMODE_NONINTERLACED
+};
+#endif
+
+static char drvrname[] = "NEC video driver for SMI LynxEM+";
+
+/*
+ *
+ * general utility functions
+ *
+ */
+
+static void
+smi_load_video_mode(struct smifb_info *sinfo,
+		    struct fb_var_screeninfo *video_mode)
+{
+	int bpp, width, height;
+	int hDisplaySize, hDisplay, hStart, hEnd, hTotal;
+	int vDisplay, vStart, vEnd, vTotal;
+	int dotClock;
+
+	pr_debug("smi_load_video_mode: video_mode->xres = %d\n",
+		 video_mode->xres);
+	pr_debug("                   :             yres = %d\n",
+		 video_mode->yres);
+	pr_debug("                   :             xres_virtual = %d\n",
+		 video_mode->xres_virtual);
+	pr_debug("                   :             yres_virtual = %d\n",
+		 video_mode->yres_virtual);
+	pr_debug("                   :             xoffset = %d\n",
+		 video_mode->xoffset);
+	pr_debug("                   :             yoffset = %d\n",
+		 video_mode->yoffset);
+	pr_debug("                   :             bits_per_pixel = %d\n",
+		 video_mode->bits_per_pixel);
+
+	/* smifb_blank(1, (struct fb_info*)sinfo); */
+	bpp = video_mode->bits_per_pixel;
+	if (bpp == 16 && video_mode->green.length == 5)
+		bpp = 15;
+
+	/* horizontal params */
+	width = video_mode->xres_virtual;
+	hDisplaySize = video_mode->xres;	/* number of pixels for one horizontal line */
+	hDisplay = (hDisplaySize / 8) - 1;	/* number of character clocks */
+	hStart = (hDisplaySize + video_mode->right_margin) / 8 + 2;	/* h-blank start character clocks */
+	hEnd = (hDisplaySize + video_mode->right_margin + video_mode->hsync_len) / 8 - 1;	/* h-sync end */
+	hTotal = (hDisplaySize + video_mode->right_margin + video_mode->hsync_len + video_mode->left_margin) / 8 - 1;	/* character clock from h-sync to next h-sync */
+
+	/* vertical params */
+	height = video_mode->yres_virtual;
+	vDisplay = video_mode->yres - 1;	/* number of lines */
+	vStart = video_mode->yres + video_mode->lower_margin - 1;	/* v-sync pulse start */
+	vEnd = video_mode->yres + video_mode->lower_margin + video_mode->vsync_len - 1;	/* v-sync end */
+	vTotal = video_mode->yres + video_mode->lower_margin + video_mode->vsync_len + video_mode->upper_margin + 2;	/* number of scanlines (v-blank end) */
+
+	dotClock = 1000000000 / video_mode->pixclock;
+
+	smi_set_moderegs(sinfo, bpp, width, height,
+			 hDisplaySize,
+			 hDisplay, hStart, hEnd, hTotal,
+			 vDisplay, vStart, vEnd, vTotal,
+			 dotClock, video_mode->sync);
+}
+
+/*
+ *
+ * framebuffer operations
+ *
+ */
+static int
+smifb_get_fix(struct fb_fix_screeninfo *fix, int con, struct fb_info *info)
+{
+	struct smifb_info *sinfo = (struct smifb_info *)info;
+
+	pr_debug("smifb_get_fix");
+	fix->smem_start = sinfo->fb_base_phys;
+	fix->smem_len = sinfo->fbsize;
+	fix->mmio_start = sinfo->dpr_base_phys;
+	fix->mmio_len = sinfo->dpport_size;
+
+	fix->xpanstep = 0;	/* FIXME: no xpanstep for now */
+	fix->ypanstep = 1;	/* FIXME: no ypanstep for now */
+	fix->ywrapstep = 0;	/* FIXME: no ywrap for now */
+
+	return 0;
+}
+
+static int vgxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			   unsigned blue, unsigned transp, struct fb_info *info)
+{
+	if (regno > 15)
+		return 1;
+
+	((u16 *) (info->pseudo_palette))[regno] =
+	    (red & 0xf800) | (green & 0xfc00 >> 5) | (blue & 0xf800 >> 11);
+	return 0;
+}
+
+/*
+ * Initialization helper functions
+ *
+ */
+/* kernel interface */
+static struct fb_ops smifb_ops = {
+	.owner = THIS_MODULE,
+	.fb_setcolreg = vgxfb_setcolreg,
+	.fb_fillrect = cfb_fillrect,
+	.fb_copyarea = cfb_copyarea,
+	.fb_imageblit = cfb_imageblit,
+	.fb_cursor = soft_cursor,
+};
+
+/*
+ * VGA registers
+ *
+ */
+static void Unlock(struct smifb_info *sinfo)
+{
+	pr_debug("Unlock");
+	regSR_write(sinfo->mmio, 0x33, regSR_read(sinfo->mmio, 0x33) & 0x20);
+}
+
+static void Lock(struct smifb_info *sinfo)
+{
+	pr_debug("Lock");
+}
+
+static void UnlockVGA(struct smifb_info *sinfo)
+{
+	pr_debug("UnlockVGA");
+	regCR_write(sinfo->mmio, 0x11, regCR_read(sinfo->mmio, 0x11) & 0x7f);
+}
+
+static void LockVGA(struct smifb_info *sinfo)
+{
+	pr_debug("LockVGA");
+	regCR_write(sinfo->mmio, 0x11, regCR_read(sinfo->mmio, 0x11) | 0x80);
+}
+
+static struct fb_fix_screeninfo vgxfb_fix = {
+	.id = "vgxFB",
+	.type = FB_TYPE_PACKED_PIXELS,
+	.visual = FB_VISUAL_TRUECOLOR,
+#ifdef CONFIG_DISPLAY_1024x768
+	.line_length = 1024 * 2,
+#else
+	.line_length = 640 * 2,
+#endif
+	.accel = FB_ACCEL_NONE,
+};
+
+static u32 colreg[17];
+
+/*
+ * PCI bus
+ *
+ */
+static int __devinit
+smifb_probe(struct pci_dev *pd, const struct pci_device_id *ent)
+{
+	int len;
+	int res;
+	u16 cmd;
+	struct smifb_info *sinfo;
+	struct fb_info *info;
+
+	pr_debug("smifb_probe");
+
+	pr_debug("vendor id        %04x\n", pd->vendor);
+	pr_debug("device id        %04x\n", pd->device);
+	pr_debug("sub vendor id    %04x\n", pd->subsystem_vendor);
+	pr_debug("sub device id    %04x\n", pd->subsystem_device);
+
+	pr_debug("base0 start addr %08x\n",
+		 (unsigned int)pci_resource_start(pd, 0));
+	pr_debug("base0 end   addr %08x\n",
+		 (unsigned int)pci_resource_end(pd, 0));
+	pr_debug("base0 region len %08x\n",
+		 (unsigned int)pci_resource_len(pd, 0));
+	pr_debug("base0 flags      %08x\n",
+		 (unsigned int)pci_resource_flags(pd, 0));
+
+	pci_read_config_word(pd, PCI_STATUS, &cmd);
+	pr_debug("PCI status      %04x\n", cmd);
+
+	pci_read_config_word(pd, PCI_COMMAND, &cmd);
+	pr_debug("PCI command      %04x\n", cmd);
+
+	cmd |= PCI_COMMAND_MEMORY | PCI_COMMAND_IO;
+	pci_write_config_word(pd, PCI_COMMAND, cmd);
+
+	pci_read_config_word(pd, PCI_STATUS, &cmd);
+	pr_debug("PCI status      %04x\n", cmd);
+	pci_read_config_word(pd, PCI_COMMAND, &cmd);
+	pr_debug("PCI command      %04x\n", cmd);
+
+	/* allocate memory resources */
+	sinfo = kmalloc(sizeof(struct smifb_info), GFP_KERNEL);
+	if (!sinfo) {
+		goto err_out;
+	}
+	memset(sinfo, 0, sizeof(struct smifb_info));
+
+	/* driver name */
+	sinfo->drvr_name = drvrname;
+
+	sinfo->pd = pd;
+	sinfo->base_phys = pci_resource_start(sinfo->pd, 0);	/* Frame Buffer base address */
+	len = pci_resource_len(sinfo->pd, 0);
+	pr_debug("len = %lX\n", len);
+	if (!request_mem_region(sinfo->base_phys, len, "smifb")) {
+		printk(KERN_ERR "cannot reserve FrameBuffer and MMIO region\n");
+		goto err_out_kfree;
+	}
+
+	if ((res = pci_enable_device(sinfo->pd)) < 0) {
+		printk(KERN_ERR "smifb: failed to enable -- err %d\n", res);
+		goto err_out_free_base;
+	}
+
+	pci_read_config_word(pd, PCI_COMMAND, &cmd);
+	pr_debug(KERN_INFO "PCI command      %04x\n", cmd);
+
+	{
+		unsigned int pseudo_io, pseudo_io_len;
+		unsigned char *pseudo_io_p;
+
+		*(unsigned long *)0xbe000610 = 0x10000012;	/* CHANGE to PCI IO ACCESS */
+		asm("sync");
+		pseudo_io = pci_resource_start(sinfo->pd, 0);
+		pseudo_io_len = pci_resource_len(sinfo->pd, 0);
+		pseudo_io_p = ioremap(pseudo_io, pseudo_io_len);
+
+		VGA_WRITE8(pseudo_io_p, 0x3c3, 0x40);
+		regSR_write(pseudo_io_p, 0x00, 0x00);
+		regSR_write(pseudo_io_p, 0x17, 0xe2);
+		regSR_write(pseudo_io_p, 0x18, 0xff);
+
+		iounmap(pseudo_io_p);
+		*(unsigned long *)0xbe000610 = 0x10000016;	/* PCI MEM ACCESS */
+		asm("sync");
+	}
+	sinfo->base = ioremap(sinfo->base_phys, len);	/* FB+DPD+DPR+VPR+CPR+MMIO */
+	if (!sinfo->base) {
+		goto err_out_free_base;
+	}
+	switch ((sinfo->pd)->device) {
+	case PCI_DEVICE_ID_SMI_LYNX_EM_PLUS:
+		sinfo->dpport = (caddr_t) (sinfo->base + DPPORT_BASE_OFFSET);
+		sinfo->dpr = (caddr_t) (sinfo->base + DP_BASE_OFFSET);
+		sinfo->vpr = (caddr_t) (sinfo->base + VP_BASE_OFFSET);
+		sinfo->cpr = (caddr_t) (sinfo->base + CP_BASE_OFFSET);
+		sinfo->mmio = (caddr_t) (sinfo->base + IO_BASE_OFFSET);
+		sinfo->fb_base = (caddr_t) (sinfo->base + 0);
+		break;
+	case PCI_DEVICE_ID_SMI_LYNX_3DM:
+		sinfo->dpport =
+		    (caddr_t) (sinfo->base + LYNX3DM_DPPORT_BASE_OFFSET);
+		sinfo->dpr = (caddr_t) (sinfo->base + LYNX3DM_DP_BASE_OFFSET);
+		sinfo->vpr = (caddr_t) (sinfo->base + LYNX3DM_VP_BASE_OFFSET);
+		sinfo->cpr = (caddr_t) (sinfo->base + LYNX3DM_CP_BASE_OFFSET);
+		sinfo->mmio = (caddr_t) (sinfo->base + LYNX3DM_IO_BASE_OFFSET);
+		sinfo->fb_base =
+		    (caddr_t) (sinfo->base + LYNX3DM_FB_BASE_OFFSET);
+		break;
+	}
+	regSR_write(sinfo->mmio, 0x18, 0x11);
+
+	pr_debug("sinfo->dpport = 0x%08x\n", (u_int32_t) sinfo->dpport);
+	pr_debug("sinfo->dpr  = 0x%08x, sinfo->vpr   = 0x%08x\n",
+		 (unsigned int)sinfo->dpr, (unsigned int)sinfo->vpr);
+	pr_debug("sinfo->cpr  = 0x%08x, sinfo->mmio  = 0x%08x\n",
+		 (unsigned int)sinfo->cpr, (unsigned int)sinfo->mmio);
+
+	/* Set the chip in color mode and unlock the registers */
+	VGA_WRITE8(sinfo->mmio, 0x3c2, 0x2b);	/* Miscellaneous Output Register ( write 0x3c2, read 0x3cc ) */
+
+	Unlock(sinfo);
+	UnlockVGA(sinfo);
+
+	/* save the current chip status */
+	switch ((sinfo->pd)->device) {
+	case PCI_DEVICE_ID_SMI_LYNX_EM_PLUS:
+		regSR_write(sinfo->mmio, 0x62, 0xff);
+		regSR_write(sinfo->mmio, 0x6a, 0x0c);
+		regSR_write(sinfo->mmio, 0x6b, 0x02);
+
+		*(u32 *) (sinfo->fb_base + 4) = 0xaa551133;
+		pr_debug("       *(u32 *)(sinfo->fb_base +4) = 0x%08x\n",
+			 *(u32 *) (sinfo->fb_base + 4));
+		if (*(u32 *) (sinfo->fb_base + 4) != 0xaa551133) {
+			/* Program the MCLK to 130MHz */
+			regSR_write(sinfo->mmio, 0x6a, 0x10);
+			regSR_write(sinfo->mmio, 0x6b, 0x02);
+			regSR_write(sinfo->mmio, 0x62, 0x3e);
+			sinfo->fbsize = 2 * 1024 * 1024;	/* LynxEM+ */
+			pr_debug
+			    ("ChipID = LynxEM+. Force the MCLK to 85MHz and the memory size to 2MiB\n");
+		} else {
+			sinfo->fbsize = 4 * 1024 * 1024;	/* LynxEM4+ */
+			pr_debug
+			    ("ChipID = LynxEM4+. Force the MCLK to 85MHz and the memory size to 4MiB\n");
+		}
+		sinfo->fb_base_phys = sinfo->base_phys;
+		break;
+	case PCI_DEVICE_ID_SMI_LYNX_3DM:
+		{
+			int tmp;
+			int mem_table[4] = { 8, 16, 0, 4 };
+			tmp = (regSR_read(sinfo->mmio, 0x76) & 0xff);
+			pr_debug("%02x\n", tmp);
+			sinfo->fbsize = mem_table[(tmp >> 6)] * 1024 * 1024;
+
+			regSR_write(sinfo->mmio, 0x62, 0xff);
+			regSR_write(sinfo->mmio, 0x6a, 0x0c);
+			regSR_write(sinfo->mmio, 0x6b, 0x02);
+
+			sinfo->fb_base_phys =
+			    sinfo->base_phys + LYNX3DM_FB_BASE_OFFSET;
+		}
+		break;
+	default:
+		/* this driver supports only LynxEM+/EM4+ */
+		goto err_out_free_base;
+	};
+
+	info = &(sinfo->info);
+	smifb_get_fix(&vgxfb_fix, -1, info);
+
+	info->flags = FBINFO_FLAG_DEFAULT;
+	info->fbops = &smifb_ops;
+	info->var = smifb_default_var;
+	info->fix = vgxfb_fix;
+	info->pseudo_palette = colreg;
+	info->screen_base = sinfo->fb_base;
+
+	smi_load_video_mode(sinfo, &smifb_default_var);
+
+	if (register_framebuffer(&sinfo->info) < 0) {
+		goto err_out_free_base;
+	}
+	pci_set_drvdata(pd, sinfo);
+
+	printk(KERN_INFO "smifb: " "framebuffer (%s)\n", sinfo->drvr_name);
+
+	return 0;
+
+      err_out_free_base:
+	release_mem_region(sinfo->base_phys, len);
+      err_out_kfree:
+	kfree(sinfo);
+      err_out:
+	return -ENODEV;
+}
+
+static void __devexit smifb_remove(struct pci_dev *pd)
+{
+	struct smifb_info *sinfo = pci_get_drvdata(pd);
+	pr_debug("smifb_remove");
+
+	if (!sinfo)
+		return;
+
+	unregister_framebuffer(&sinfo->info);
+
+	/* stop the lynx chip */
+	release_mem_region(sinfo->base_phys, pci_resource_len(sinfo->pd, 0));
+	kfree(sinfo);
+	pci_set_drvdata(pd, NULL);
+}
+
+/*
+ * Initialization
+ *
+ */
+#ifndef MODULE
+int __init smifb_setup(char *options)
+{
+	pr_debug("smifb_setup");
+
+	if (!options || options)
+		return 0;
+	return 0;
+}
+#endif				/* not MODULE */
+
+static struct pci_driver smifb_driver = {
+	.name = "smifb",
+	.id_table = smifb_pci_tbl,
+	.probe = smifb_probe,
+	.remove = __devexit_p(smifb_remove),
+};
+
+/*
+ * Driver initialization
+ */
+int __init smifb_init(void)
+{
+	pr_debug("smifb_init");
+	return pci_module_init(&smifb_driver);
+}
+
+/*
+ * modularization
+ *
+ */
+#ifdef MODULE
+static void __exit smifb_exit(void)
+{
+	pci_unregister_driver(&smifb_driver);
+}
+
+module_init(smifb_init);
+module_exit(smifb_exit);
+
+#endif				/* MODULE */
+
+module_init(smifb_init);
+
+MODULE_AUTHOR("Sergey Podstavin");
+MODULE_DESCRIPTION("Framebuffer driver for Silicon Motion Lynx 3DM+");
+MODULE_LICENSE("GPL");
diff -Naurp --exclude=CVS linux_save/drivers/video/smi/smifb.h linux_mips/drivers/video/smi/smifb.h
--- linux_save/drivers/video/smi/smifb.h	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/video/smi/smifb.h	2005-05-31 17:00:36.000000000 +0400
@@ -0,0 +1,89 @@
+/*
+ * drivers/video/smi/smifb.h
+ *
+ * LynxEM+/EM4+(Silicon Motion Inc.) fb driver	for VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#ifndef __SMIFB_H__
+#define __SMIFB_H__
+
+#define FBCON_HAS_CFB16
+
+enum ScreenModes {
+	DISPLAY_640x480x16,
+	DISPLAY_800x600x16,
+	DISPLAY_1024x768x16,
+	DISPLAY_640x480x24,
+	DISPLAY_800x600x24,
+	DISPLAY_LCD_400x232x16,
+	modeNums,
+};
+
+#define SMI_DEFAULT_MODE	DISPLAY_640x480x16
+
+#define SIZE_SR00_SR04		(0x04 - 0x00 + 1)
+#define SIZE_SR10_SR24		(0x24 - 0x10 + 1)
+#define SIZE_SR30_SR75		(0x75 - 0x30 + 1)
+#define SIZE_SR80_SR93		(0x93 - 0x80 + 1)
+#define SIZE_SRA0_SRAF		(0xAF - 0xA0 + 1)
+#define SIZE_GR00_GR08		(0x08 - 0x00 + 1)
+#define SIZE_AR00_AR14		(0x14 - 0x00 + 1)
+#define SIZE_CR00_CR18		(0x18 - 0x00 + 1)
+#define SIZE_CR30_CR4D		(0x4D - 0x30 + 1)
+#define SIZE_CR90_CRA7		(0xA7 - 0x90 + 1)
+
+struct smi_mode_regs {
+	int mode;
+	u8 reg_MISC;
+	u8 reg_SR00_SR04[SIZE_SR00_SR04];	/* SEQ00--04 (SEQ) */
+	u8 reg_SR10_SR24[SIZE_SR10_SR24];	/* SCR10--1F, PDR20--24 (SYS),(PWR) */
+	u8 reg_SR30_SR75[SIZE_SR30_SR75];	/* FPR30--5A, MCR60--62, CCR65--6F  GPR70--75 (LCD),(MEM),(CLK),(GP) */
+	u8 reg_SR80_SR93[SIZE_SR80_SR93];	/* PHR80-81, POP82--86, HCR88-8D, POP90--93 (CURS),(ICON),(CURS),(ICON) */
+	u8 reg_SRA0_SRAF[SIZE_SRA0_SRAF];	/* FPRA0--AF (LCD) */
+	u8 reg_GR00_GR08[SIZE_GR00_GR08];	/* GR00--08 (GC) */
+	u8 reg_AR00_AR14[SIZE_AR00_AR14];	/* ATR00--14 (ATTR) */
+	u8 reg_CR00_CR18[SIZE_CR00_CR18];	/* CRT00--18 (CRTC) */
+	u8 reg_CR30_CR4D[SIZE_CR30_CR4D];	/* CRT30--3F, SVR40--4D (ECRTC),(SHADOW) */
+	u8 reg_CR90_CRA7[SIZE_CR90_CRA7];	/* CRT90--9B,9E,9F,A0--A5,A6,A7, (DDA),(EC2),(EC1)(VCLUT),(VC),(HC) */
+};
+
+typedef struct {
+	unsigned char red, green, blue, transp;
+} smi_cfb8_cmap_t;
+
+struct smifb_info;
+struct smifb_info {
+	struct fb_info info;	/* kernel framebuffer info */
+	const char *drvr_name;	/* Silicon Motion hardware board type */
+	struct pci_dev *pd;	/* descripbe the PCI device */
+	unsigned long base_phys;	/* physical base address                  */
+
+	/* PCI base physical addresses */
+	unsigned long fb_base_phys;	/* physical Frame Buffer base address                  */
+	unsigned long dpr_base_phys;	/* physical Drawing Processor base address             */
+	unsigned long vpr_base_phys;	/* physical Video Processor base address               */
+	unsigned long cpr_base_phys;	/* physical Capture Processor base address             */
+	unsigned long mmio_base_phys;	/* physical MMIO spase (VGA + SMI regs ?) base address */
+	unsigned long dpport_base_phys;	/* physical Drawing Processor Data Port base address   */
+	int dpport_size;	/* size of Drawin Processor Data Port memory space     */
+
+	/* PCI base virtual addresses */
+	caddr_t base;		/* address of base */
+	caddr_t fb_base;	/* address of frame buffer base */
+	caddr_t dpr;		/* Drawing Processor Registers  */
+	caddr_t vpr;		/* Video Processor Registers    */
+	caddr_t cpr;		/* Capture Processor Registers  */
+	caddr_t mmio;		/* Memory Mapped I/O Port       */
+	caddr_t dpport;		/* Drawing Processor Data       */
+
+	int fbsize;		/* Frame-Buffer memory size */
+};
+
+#endif				/* __SMIFB_H__ */
diff -Naurp --exclude=CVS linux_save/drivers/video/smi/smi_hw.c linux_mips/drivers/video/smi/smi_hw.c
--- linux_save/drivers/video/smi/smi_hw.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/video/smi/smi_hw.c	2005-05-31 17:00:36.000000000 +0400
@@ -0,0 +1,188 @@
+/*
+ * drivers/video/smi/smi_hw.c
+ *
+ * LynxEM+/EM4+(Silicon Motion Inc.) fb driver for VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include "smifb.h"
+#include "smi_hw.h"
+#include "smi_params.h"
+
+/*
+ * set mode registers
+ */
+void
+smi_set_moderegs(struct smifb_info *sinfo,
+		 int bpp, int width, int height,
+		 int hDisplaySize,
+		 int hDisplay, int hStart, int hEnd, int hTotal,
+		 int vDisplay, int vStart, int vEnd, int vTotal,
+		 int dotClock, int sync)
+{
+	int i;
+	int tmp_mode = SMI_DEFAULT_MODE;
+	int lineLength;
+	struct smi_mode_regs curMode;
+
+	pr_debug("smi_set_moderegs");
+	pr_debug("bpp = %d, width = %d, height = %d\n", bpp, width, height);
+	pr_debug("hDisplaySize = %d\n", hDisplaySize);
+	pr_debug("hDisplay = %d, hStart = %d, hEnd = %d, hTotal = %d\n",
+		 hDisplay, hStart, hEnd, hTotal);
+	pr_debug("vDisplay = %d, vStart = %d, vEnd = %d, vTotal = %d\n",
+		 vDisplay, vStart, vEnd, vTotal);
+	pr_debug("dotClock = %d\n", dotClock);
+
+	lineLength = width * bpp / 8;
+
+	switch (bpp) {
+#ifdef FBCON_HAS_CFB8
+	case 8:
+		if (hDisplaySize <= 640)
+			tmp_mode = DISPLAY_640x480x8;
+		else if (width <= 800)
+			tmp_mode = DISPLAY_800x600x8;
+		else if (width <= 1024)
+			tmp_mode = DISPLAY_1024x768x8;
+		else if (width <= 1280)
+			tmp_mode = DISPLAY_1280x1024x8;
+		reg_DPR10(sinfo) = (lineLength << 16) | lineLength;	/* RowPitch */
+		reg_DPR1E(sinfo) = 0x0005;
+		reg_DPR3C(sinfo) = (lineLength << 16) | lineLength;	/* Dst & Src Window Width */
+		reg_VPR00(sinfo) = 0x0 << 16;
+		break;
+#endif
+#ifdef FBCON_HAS_CFB16
+	case 16:
+		if (hDisplaySize <= 400)
+			tmp_mode = DISPLAY_LCD_400x232x16;
+		if (hDisplaySize <= 640)
+			tmp_mode = DISPLAY_640x480x16;
+		else if (width <= 800)
+			tmp_mode = DISPLAY_800x600x16;
+		else if (width <= 1024)
+			tmp_mode = DISPLAY_1024x768x16;
+		reg_DPR10(sinfo) = (lineLength / 2 << 16) | lineLength / 2;	/* RowPitch */
+		reg_DPR1E(sinfo) = 0x0015;
+		reg_DPR3C(sinfo) = (lineLength / 2 << 16) | lineLength / 2;	/* Dst & Src Window Width */
+		reg_VPR00(sinfo) = 0x2 << 16;
+		break;
+#endif
+#ifdef FBCON_HAS_CFB24
+	case 24:
+		if (hDisplaySize <= 640)
+			tmp_mode = DISPLAY_640x480x24;
+		else if (width <= 800)
+			tmp_mode = DISPLAY_800x600x24;
+		reg_DPR10(sinfo) = (lineLength / 3 << 16) | lineLength / 3;	/* RowPitch */
+		reg_DPR1E(sinfo) = 0x0035;
+		reg_DPR3C(sinfo) = (lineLength / 3 << 16) | lineLength / 3;	/* Dst & Src Window Width */
+		reg_VPR00(sinfo) = 0x4 << 16;
+		break;
+#endif
+	};
+
+	for (i = 0; i < modeNums; i++) {
+		if (ModeInitParams[i].mode == tmp_mode)
+			break;
+	}
+	if (i == modeNums)
+		tmp_mode = SMI_DEFAULT_MODE;
+
+	memcpy(&curMode, &ModeInitParams[tmp_mode],
+	       sizeof(struct smi_mode_regs));
+
+	/*
+	 * Override some Mode Params
+	 */
+	/* MISC Reg */
+	curMode.reg_MISC = 0x30 | (hDisplay == 640) ? 0x03 : 0x0b;
+	if (sync & FB_SYNC_HOR_HIGH_ACT)
+		curMode.reg_MISC |= 0x40;
+	if (sync & FB_SYNC_VERT_HIGH_ACT)
+		curMode.reg_MISC |= 0x80;
+
+	/* CRTC */
+	curMode.reg_CR00_CR18[0x00] = (u8) (hTotal - 4);
+	curMode.reg_CR00_CR18[0x01] = (u8) hDisplay;
+	curMode.reg_CR00_CR18[0x02] = (u8) hDisplay;
+	curMode.reg_CR00_CR18[0x03] = 0x00;
+	curMode.reg_CR00_CR18[0x04] = (u8) hStart;
+	curMode.reg_CR00_CR18[0x05] = (hEnd & 0x1f);
+	curMode.reg_CR00_CR18[0x06] = (u8) (vTotal & 0xff);
+	curMode.reg_CR00_CR18[0x07] = (u8) (((vStart >> 9) & 0x01) << 7)
+	    | (u8) (((vDisplay >> 9) & 0x01) << 6)
+	    | (u8) (((vTotal >> 9) & 0x01) << 5)
+	    | 1 << 4		/* D (LC) */
+	    | (u8) (((vStart >> 8) & 0x01) << 2)
+	    | (u8) (((vDisplay >> 8) & 0x01) << 1)
+	    | (u8) ((vTotal >> 8) & 0x01);
+
+	curMode.reg_CR00_CR18[0x09] = (u8) (vDisplay >> 9) << 5 | 1 << 6;	/* D (LC bit9) */
+	curMode.reg_CR00_CR18[0x10] = (u8) (vStart & 0xff);
+	curMode.reg_CR00_CR18[0x11] = (u8) (vEnd & 0xf);
+	curMode.reg_CR00_CR18[0x12] = (u8) (vDisplay & 0xff);
+	curMode.reg_CR00_CR18[0x13] = ((width / 8) * ((bpp + 1) / 8)) & 0xFF;
+	curMode.reg_CR00_CR18[0x15] = (u8) (vDisplay & 0xff);
+	curMode.reg_CR00_CR18[0x16] = 0x00;
+	curMode.reg_CR00_CR18[0x14] = (hDisplaySize > 1024) ? 0x00 : 0x40;	/* D *//* Underline Location */
+
+	/* Extended CRTC */
+	curMode.reg_CR30_CR4D[0x30 - 0x30] = (u8) (((vTotal >> 10) & 0x01) << 3)
+	    | (u8) (((vDisplay >> 10) & 0x01) << 1)
+	    | (u8) ((vStart >> 10) & 0x1);	/* D (CRTD) (CVDER) */
+
+	curMode.reg_SR30_SR75[0x32] = 0xff;	/* (Memory Type and Timig Control Reg) */
+
+	for (i = 0; i <= SIZE_SR00_SR04; i++)
+		regSR_write(sinfo->mmio, 0x00 + i, curMode.reg_SR00_SR04[i]);
+	for (i = 0; i <= SIZE_SR10_SR24; i++)
+		regSR_write(sinfo->mmio, 0x10 + i, curMode.reg_SR10_SR24[i]);
+	for (i = 0; i <= SIZE_SR30_SR75; i++) {
+		regSR_write(sinfo->mmio, 0x30 + i, curMode.reg_SR30_SR75[i]);
+	}
+	for (i = 0; i <= SIZE_SR80_SR93; i++)
+		regSR_write(sinfo->mmio, 0x80 + i, curMode.reg_SR80_SR93[i]);
+	for (i = 0; i <= SIZE_SRA0_SRAF; i++)
+		regSR_write(sinfo->mmio, 0xA0 + i, curMode.reg_SRA0_SRAF[i]);
+	for (i = 0; i <= SIZE_GR00_GR08; i++)
+		regGR_write(sinfo->mmio, 0x00 + i, curMode.reg_GR00_GR08[i]);
+	for (i = 0; i <= SIZE_AR00_AR14; i++)
+		regAR_write(sinfo->mmio, 0x00 + i, curMode.reg_AR00_AR14[i]);
+	for (i = 0; i <= SIZE_CR00_CR18; i++)
+		regCR_write(sinfo->mmio, 0x00 + i, curMode.reg_CR00_CR18[i]);
+	for (i = 0; i <= SIZE_CR30_CR4D; i++)
+		regCR_write(sinfo->mmio, 0x30 + i, curMode.reg_CR30_CR4D[i]);
+	for (i = 0; i <= SIZE_CR90_CRA7; i++)
+		regCR_write(sinfo->mmio, 0x90 + i, curMode.reg_CR90_CRA7[i]);
+
+	/* SetMemoryMapRegisters */
+	reg_DPR14(sinfo) = 0xffffffff;	/* FG color */
+	reg_DPR18(sinfo) = 0x00000000;	/* BG color */
+	reg_DPR24(sinfo) = 0xffffffff;	/* Color Mask */
+	reg_DPR28(sinfo) = 0xffff;	/* Masks */
+	reg_DPR2C(sinfo) = 0;
+	reg_DPR30(sinfo) = 0;
+	reg_DPR34(sinfo) = 0xffffffff;
+	reg_DPR38(sinfo) = 0xffffffff;
+	reg_DPR40(sinfo) = 0;
+	reg_DPR44(sinfo) = 0;
+	reg_VPR0C(sinfo) = 0;
+	reg_VPR10(sinfo) = ((lineLength / 8 + 2) << 16) | (lineLength / 8);
+	reg_VPR40(sinfo) = 0;
+	reg_VPR28(sinfo) = 0x00000000;
+	reg_VPR2C(sinfo) = ((hDisplaySize - 1) << 16) | (vDisplay);
+	reg_VPR30(sinfo) = 0x00000000;
+	reg_VPR34(sinfo) = (lineLength << 16) | lineLength;
+}
diff -Naurp --exclude=CVS linux_save/drivers/video/smi/smi_hw.h linux_mips/drivers/video/smi/smi_hw.h
--- linux_save/drivers/video/smi/smi_hw.h	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/video/smi/smi_hw.h	2005-05-31 17:00:36.000000000 +0400
@@ -0,0 +1,197 @@
+/*
+ * drivers/video/smi/smi_hw.h
+ *
+ * LynxEM+/EM4+(Silicon Motion Inc.) fb driver	for VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef __SMI_HW_H__
+#define __SMI_HW_H__
+
+#include "smifb.h"
+
+#define DPPORT_BASE_OFFSET		0x400000
+#define DP_BASE_OFFSET			0x408000
+#define VP_BASE_OFFSET			0x40c000
+#define CP_BASE_OFFSET			0x40e000
+#define IO_BASE_OFFSET			0x700000
+
+#define DPPORT_REGION_SIZE		(32*1024)
+#define DPREG_REGION_SIZE		(16*1024)
+#define VPREG_REGION_SIZE		(8*1024)
+#define CPREG_REGION_SIZE		(8*1024)
+#define MMIO_REGION_SIZE		(1*1024*1024)
+
+#define LYNX3DM_DPPORT_BASE_OFFSET		0x100000
+#define LYNX3DM_DP_BASE_OFFSET			0x000000
+#define LYNX3DM_VP_BASE_OFFSET			0x000800
+#define LYNX3DM_CP_BASE_OFFSET			0x001000
+#define LYNX3DM_IO_BASE_OFFSET			0x0c0000
+#define LYNX3DM_FB_BASE_OFFSET			0x200000
+
+#define LYNX3DM_DPPORT_REGION_SIZE		(1024*1024)
+#define LYNX3DM_DPREG_REGION_SIZE		(2*1024)
+#define LYNX3DM_VPREG_REGION_SIZE		(2*1024)
+#define LYNX3DM_CPREG_REGION_SIZE		(2*1024)
+#define LYNX3DM_MMIO_REGION_SIZE		(256*1024)
+
+extern void smi_set_moderegs(struct smifb_info *sinfo,
+			     int bpp, int width, int height,
+			     int hDisplaySize,
+			     int hDisplay, int hStart, int hEnd, int hTotal,
+			     int vDisplay, int vStart, int vEnd, int vTotal,
+			     int dotClock, int sync);
+
+#define MMIO_OUT8(p, r, d)	(((volatile u8 *)(p))[r] = (d))
+#define MMIO_OUT16(p, r, d)	(((volatile u16 *)(p))[(r)>>1] = (d))
+#define MMIO_OUT32(p, r, d)	(((volatile u32 *)(p))[(r)>>2] = (d))
+#define MMIO_IN8(p, r)		(((volatile u8 *)(p))[(r)])
+#define MMIO_IN16(p, r)		(((volatile u16 *)(p))[(r)>>1])
+#define MMIO_IN32(p, r)		(((volatile u32 *)(p))[(r)>>2])
+
+static inline u8 VGA_READ8(u8 * base, uint reg)
+{
+	return MMIO_IN8(base, reg);
+}
+
+static inline void VGA_WRITE8(u8 * base, uint reg, u8 data)
+{
+	MMIO_OUT8(base, reg, data);
+}
+
+static inline u8 VGA_READ8_INDEX(u8 * base, u8 index)
+{
+	VGA_WRITE8(base, 0x3c4, index);
+	return VGA_READ8(base, 0x3c5);
+}
+
+static inline void VGA_WRITE8_INDEX(u8 * base, u8 index, u8 data)
+{
+	VGA_WRITE8(base, 0x3c4, index);
+	VGA_WRITE8(base, 0x3c5, data);
+}
+
+static inline u8 regSR_read(u8 * base, u8 index)
+{
+	VGA_WRITE8(base, 0x3c4, index);
+	return VGA_READ8(base, 0x3c5);
+}
+
+static inline void regSR_write(u8 * base, u8 index, u8 data)
+{
+	VGA_WRITE8(base, 0x3c4, index);
+	VGA_WRITE8(base, 0x3c5, data);
+}
+
+static inline u8 regCR_read(u8 * base, u8 index)
+{
+	VGA_WRITE8(base, 0x3d4, index);
+	return VGA_READ8(base, 0x3d5);
+}
+
+static inline void regCR_write(u8 * base, u8 index, u8 data)
+{
+	VGA_WRITE8(base, 0x3d4, index);
+	VGA_WRITE8(base, 0x3d5, data);
+}
+
+static inline u8 regGR_read(u8 * base, u8 index)
+{
+	VGA_WRITE8(base, 0x3ce, index);
+	return VGA_READ8(base, 0x3cf);
+}
+
+static inline void regGR_write(u8 * base, u8 index, u8 data)
+{
+	VGA_WRITE8(base, 0x3ce, index);
+	VGA_WRITE8(base, 0x3cf, data);
+}
+
+static inline u8 regAR_read(u8 * base, u8 index)
+{
+	(void)VGA_READ8(base, 0x3da);	/* reset flip-flop */
+	VGA_WRITE8(base, 0x3c0, index);
+	return VGA_READ8(base, 0x3c1);
+}
+
+static inline void regAR_write(u8 * base, u8 index, u8 data)
+{
+	(void)VGA_READ8(base, 0x3da);	/* reset flip-flop */
+	VGA_WRITE8(base, 0x3c0, index);
+	VGA_WRITE8(base, 0x3c0, data);
+}
+
+/*
+ * LynxEM+ registers
+ */
+
+/* Drawing Engine Control Registers */
+#define reg_DPR00(x)	*(u16 *)((x)->dpr+0x00)	/* Source Y or K2                                       */
+#define reg_DPR02(x)	*(u16 *)((x)->dpr+0x02)	/* Source X or K1                                       */
+#define reg_DPR04(x)	*(u16 *)((x)->dpr+0x04)	/* Destination Y or Start Y                             */
+#define reg_DPR06(x)	*(u16 *)((x)->dpr+0x06)	/* Destination X or Start X                             */
+#define reg_DPR08(x)	*(u16 *)((x)->dpr+0x08)	/* Dimension Y or Error Term                            */
+#define reg_DPR0A(x)	*(u16 *)((x)->dpr+0x0A)	/* Dimension X or Vector Length                         */
+#define reg_DPR0C(x)	*(u16 *)((x)->dpr+0x0C)	/* ROP and Miscellaneous Control                        */
+#define reg_DPR0E(x)	*(u16 *)((x)->dpr+0x0E)	/* Drawing Engine Commands and Control                  */
+#define reg_DPR10(x)	*(u16 *)((x)->dpr+0x10)	/* Source Row Pitch                                     */
+#define reg_DPR12(x)	*(u16 *)((x)->dpr+0x12)	/* Destination Row Picth                                */
+#define reg_DPR14(x)	*(u32 *)((x)->dpr+0x14)	/* Foreground Colors                                    */
+#define reg_DPR18(x)	*(u32 *)((x)->dpr+0x18)	/* Background Colors                                    */
+#define reg_DPR1C(x)	*(u16 *)((x)->dpr+0x1C)	/* Stretch Source Height Y                              */
+#define reg_DPR1E(x)	*(u16 *)((x)->dpr+0x1E)	/* Drawing Engine DataFormat and Location Format Select */
+#define reg_DPR20(x)	*(u32 *)((x)->dpr+0x20)	/* Color Compare                                        */
+#define reg_DPR24(x)	*(u32 *)((x)->dpr+0x24)	/* Color Compare Mask                                   */
+#define reg_DPR28(x)	*(u16 *)((x)->dpr+0x28)	/* Bit Mask                                             */
+#define reg_DPR2A(x)	*(u16 *)((x)->dpr+0x2A)	/* Byte Mask Enable                                     */
+#define reg_DPR2C(x)	*(u16 *)((x)->dpr+0x2C)	/* Scisors Left and Control                             */
+#define reg_DPR2E(x)	*(u16 *)((x)->dpr+0x2E)	/* Scisors Top                                          */
+#define reg_DPR30(x)	*(u16 *)((x)->dpr+0x30)	/* Scisors Right                                        */
+#define reg_DPR32(x)	*(u16 *)((x)->dpr+0x32)	/* Scisors Bottom                                       */
+#define reg_DPR34(x)	*(u32 *)((x)->dpr+0x34)	/* Mono Pattern Low                                     */
+#define reg_DPR38(x)	*(u32 *)((x)->dpr+0x38)	/* Mono Pattern High                                    */
+#define reg_DPR3C(x)	*(u32 *)((x)->dpr+0x3C)	/* XY Addressing Destination & Source Window Widths     */
+#define reg_DPR40(x)	*(u32 *)((x)->dpr+0x40)	/* Source Base Address                                  */
+#define reg_DPR44(x)	*(u32 *)((x)->dpr+0x44)	/* Destination Base Address                             */
+
+/* Video Processor Control Registers */
+#define reg_VPR00(x)	*(u32 *)((x)->vpr+0x00)	/* Miscellaneous Graphics and Video Control                 */
+#define reg_VPR04(x)	*(u32 *)((x)->vpr+0x04)	/* Color Keys                                               */
+#define reg_VPR08(x)	*(u32 *)((x)->vpr+0x08)	/* Color Key Masks                                          */
+#define reg_VPR0C(x)	*(u32 *)((x)->vpr+0x0C)	/* Data Source Start Address for Extended Graphics Modes    */
+#define reg_VPR10(x)	*(u32 *)((x)->vpr+0x10)	/* Data Source Width and Offset for Extended Graphics Modes */
+#define reg_VPR14(x)	*(u32 *)((x)->vpr+0x14)	/* Video Window I Left and Top Boundaries                   */
+#define reg_VPR18(x)	*(u32 *)((x)->vpr+0x18)	/* Video Window I Right and Bottom Boundaries               */
+#define reg_VPR1C(x)	*(u32 *)((x)->vpr+0x1C)	/* Video Window I Source Start Address                      */
+#define reg_VPR20(x)	*(u32 *)((x)->vpr+0x20)	/* Video Window I Source Width and Offset                   */
+#define reg_VPR24(x)	*(u32 *)((x)->vpr+0x24)	/* Video Window I Stretch Factor                            */
+#define reg_VPR28(x)	*(u32 *)((x)->vpr+0x28)	/* Video Window II Left and Top Boundaries              */
+#define reg_VPR2C(x)	*(u32 *)((x)->vpr+0x2C)	/* Video Window II Right and Bottom Boundaries              */
+#define reg_VPR30(x)	*(u32 *)((x)->vpr+0x30)	/* Video Window II Source Start Address                     */
+#define reg_VPR34(x)	*(u32 *)((x)->vpr+0x34)	/* Video Window II Source Width and Offset                  */
+#define reg_VPR38(x)	*(u32 *)((x)->vpr+0x38)	/* Video Window II Stretch Factor                           */
+#define reg_VPR3C(x)	*(u32 *)((x)->vpr+0x3C)	/* Graphics and Video Controll II                           */
+#define reg_VPR40(x)	*(u32 *)((x)->vpr+0x40)	/* Graphic Scale Factor                                     */
+#define reg_VPR54(x)	*(u32 *)((x)->vpr+0x54)	/* FIFO Priority Control                                    */
+#define reg_VPR58(x)	*(u32 *)((x)->vpr+0x58)	/* FIFO Empty Request level Control                         */
+#define reg_VPR5C(x)	*(u32 *)((x)->vpr+0x5C)	/* YUV to RGB Conversion Constant                           */
+#define reg_VPR60(x)	*(u32 *)((x)->vpr+0x60)	/* Current Scan Line Position                               */
+#define reg_VPR64(x)	*(u32 *)((x)->vpr+0x64)	/* Signature Analyzer Control and Status                    */
+#define reg_VPR68(x)	*(u32 *)((x)->vpr+0x68)	/* Video Window I Stretch Factor                            */
+#define reg_VPR6C(x)	*(u32 *)((x)->vpr+0x6C)	/* Video Window II Stretch Factor                           */
+
+/* Capture Processor Control Registers */
+#define reg_CPR00(x)	*(u32 *)((x)->cpr+0x00)	/* Capture Port Control                        */
+#define reg_CPR04(x)	*(u32 *)((x)->cpr+0x04)	/* Video Source Clipping Control               */
+#define reg_CPR08(x)	*(u32 *)((x)->cpr+0x08)	/* Video Source Capture Size Control           */
+#define reg_CPR0C(x)	*(u32 *)((x)->cpr+0x0C)	/* Capture Port Buffer I Source Start Address  */
+#define reg_CPR10(x)	*(u32 *)((x)->cpr+0x10)	/* Capture Port Buffer II Source Start Address */
+#define reg_CPR14(x)	*(u32 *)((x)->cpr+0x14)	/* Capture Port Source Offset Address          */
+#define reg_CPR18(x)	*(u32 *)((x)->cpr+0x18)	/* Capture FIFO Empty Request level Control    */
+
+#endif				/* __SMI_HW_H__ */
diff -Naurp --exclude=CVS linux_save/drivers/video/smi/smi_params.h linux_mips/drivers/video/smi/smi_params.h
--- linux_save/drivers/video/smi/smi_params.h	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/video/smi/smi_params.h	2005-05-31 17:00:36.000000000 +0400
@@ -0,0 +1,442 @@
+/*
+ * drivers/video/smi/smi_params.h
+ *
+ * LynxEM+/EM4+(Silicon Motion Inc.) fb driver	for VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#ifndef __SMI_REGS_H__
+#define __SMI_REGS_H__
+
+/* register settings */
+struct smi_mode_regs ModeInitParams[modeNums] = {
+	/* mode#4 640 x 480 16Bpp 60Hz */
+	{
+	 DISPLAY_640x480x16,
+	 /* reg_MISC */
+	 0xE3,
+	 /* reg_SR00_SR04 */
+	 {
+	  0x03, 0x01, 0x0F, 0x00, 0x0E,
+	  },
+	 /* reg_SR10_SR24 */
+	 {
+	  0x03, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x10, 0x2C,
+	  0x59, 0x00, 0x20, 0x00, 0x00, 0x0F, 0x0F, 0x00,
+	  0xC4, 0x30, 0x02, 0x01, 0x01,
+	  },
+
+	 /* reg_SR30_SR75 */
+	 {
+	  0xAA, 0x03, 0xA0, 0x89, 0xC0, 0xAA, 0xAA, 0xAA,
+	  0xAA, 0xAA, 0xAA, 0xAA, 0x00, 0x00, 0x03, 0xFF,
+	  0x00, 0xFC, 0x00, 0x00, 0x20, 0x38, 0x00, 0xFC,
+	  0x20, 0x0C, 0x44, 0x20, 0x00, 0x00, 0x00, 0xAA,
+	  0x04, 0x24, 0x63, 0x4F, 0x52, 0x0B, 0xDF, 0xEA,
+	  0x04, 0x50, 0x19, 0xAA, 0xAA, 0x00, 0x00, 0xAA,
+	  0x01, 0x80, 0xFF, 0x1A, 0x1A, 0x00, 0x03, 0x00,
+	  0x50, 0x03, 0x0D, 0x02, 0x07, 0x82, 0x07, 0x04,
+	  0x00, 0x45, 0x30, 0x0C, 0x40, 0x30,
+	  },
+	 /* reg_SR80_SR93 */
+	 {
+	  0xFF, 0x07, 0x00, 0x6F, 0x7F, 0x7F, 0xFF, 0xAA,
+	  0x40, 0x01, 0xF0, 0x00, 0xFF, 0x00, 0xAA, 0xAA,
+	  0x00, 0x00, 0x00, 0x00,
+	  },
+	 /* reg_SRA0_SRAF */
+	 {
+	  0x00, 0xFF, 0xBF, 0xFF, 0xFF, 0xED, 0xED, 0xED,
+	  0x7B, 0xFF, 0xFF, 0xFF, 0xBF, 0xEF, 0xFF, 0xDF,
+	  },
+	 /* reg_GR00_GR08 */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
+	  0xFF,
+	  },
+	 /* reg_AR00_AR14 */
+	 {
+	  0x3F, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+	  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
+	  0x10, 0x00, 0x12, 0x00, 0x04,
+	  },
+	 /* reg_CR00_CR18 */
+	 {
+	  0x5F, 0x4F, 0x4F, 0x00, 0x53, 0x1F, 0x0B, 0x3E,
+	  0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0xEA, 0x0C, 0xDF, 0x50, 0x40, 0xDF, 0x00, 0xE3,
+	  0xFF,
+	  },
+	 /* reg_CR30_CR4D */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x55, 0x03, 0x20,
+	  0x00, 0x00, 0x00, 0x40, 0x00, 0xE7, 0xFF, 0xFD,
+	  0x5F, 0x4F, 0x00, 0x54, 0x00, 0x0B, 0xDF, 0x00,
+	  0xEA, 0x0C, 0x2E, 0x00, 0x4F, 0xDF,
+	  },
+	 /* reg_CR90_CRA7 */
+	 {
+	  0x56, 0xDD, 0x5E, 0xEA, 0x87, 0x44, 0x8F, 0x55,
+	  0x0A, 0x8F, 0x55, 0x0A, 0x00, 0x00, 0x18, 0x00,
+	  0x11, 0x10, 0x0B, 0x0A, 0x0A, 0x0A, 0x0A, 0x00,
+	  },
+	 },
+	/* mode#5 800 x 600 16Bpp 60Hz */
+	{
+	 DISPLAY_800x600x16,
+	 /* reg_MISC */
+	 0x2B,
+	 /* reg_SR00_SR04 */
+	 {
+	  0x03, 0x01, 0x0F, 0x03, 0x0E,
+	  },
+	 /* reg_SR10_SR24 */
+	 {
+	  0xFF, 0xBE, 0xEE, 0xFF, 0x00, 0x0E, 0x17, 0xe2,
+	  0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0xC4, 0x30, 0x02, 0x01, 0x01,
+	  },
+	 /* reg_SR30_SR75 */
+	 {
+	  0x36, 0x03, 0x20, 0x09, 0xC0, 0x36, 0x36, 0x36,
+	  0x36, 0x36, 0x36, 0x36, 0x00, 0x00, 0x03, 0xFF,
+	  0x00, 0xFC, 0x00, 0x00, 0x20, 0x18, 0x00, 0xFC,
+	  0x20, 0x0C, 0x44, 0x20, 0x00, 0x36, 0x36, 0x36,
+	  0x04, 0x48, 0x83, 0x63, 0x68, 0x72, 0x57, 0x58,
+	  0x04, 0x55, 0x59, 0x36, 0x36, 0x00, 0x00, 0x36,
+	  0x01, 0x80, 0x7E, 0x1A, 0x1A, 0x00, 0x00, 0x00,
+	  0x50, 0x03, 0x74, 0x14, 0x1C, 0x85, 0x35, 0x13,
+	  0x02, 0x45, 0x30, 0x30, 0x40, 0x20,
+	  },
+	 /* reg_SR80_SR93 */
+	 {
+	  0xFF, 0x07, 0x00, 0x6F, 0x7F, 0x7F, 0xFF, 0x36,
+	  0xF7, 0x00, 0x00, 0x00, 0xEF, 0xFF, 0x36, 0x36,
+	  0x00, 0x00, 0x00, 0x00,
+	  },
+	 /* reg_SRA0_SRAF */
+	 {
+	  0x00, 0xFF, 0xBF, 0xFF, 0xFF, 0xED, 0xED, 0xED,
+	  0x7B, 0xFF, 0xFF, 0xFF, 0xBF, 0xEF, 0xBF, 0xDF,
+	  },
+	 /* reg_GR00_GR08 */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
+	  0xFF,
+	  },
+	 /* reg_AR00_AR14 */
+	 {
+	  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+	  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
+	  0x41, 0x00, 0x0F, 0x00, 0x00,
+	  },
+	 /* reg_CR00_CR18 */
+	 {
+	  0x7F, 0x63, 0x63, 0x00, 0x68, 0x18, 0x72, 0xF0,
+	  0x00, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0x58, 0x0C, 0x57, 0x64, 0x40, 0x57, 0x00, 0xE3,
+	  0xFF,
+	  },
+	 /* reg_CR30_CR4D */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x03, 0x20,
+	  0x00, 0x00, 0x00, 0x40, 0x00, 0xE7, 0xBF, 0xFD,
+	  0x7F, 0x63, 0x00, 0x69, 0x18, 0x72, 0x57, 0x00,
+	  0x58, 0x0C, 0xE0, 0x20, 0x63, 0x57,
+	  },
+	 /* reg_CR90_CRA7 */
+	 {
+	  0x56, 0x4B, 0x5E, 0x55, 0x86, 0x9D, 0x8E, 0xAA,
+	  0xDB, 0x2A, 0xDF, 0x33, 0x00, 0x00, 0x18, 0x00,
+	  0x20, 0x1F, 0x1A, 0x19, 0x0F, 0x0F, 0x0F, 0x00,
+	  },
+	 },
+	/* mode#6 1024 x 768 16Bpp 60Hz * */
+	{
+	 DISPLAY_1024x768x16,
+	 /* reg_MISC */
+	 0xEB,
+	 /* reg_SR00_SR04 */
+	 {
+	  0x03, 0x01, 0x0F, 0x03, 0x0E,
+	  },
+	 /* reg_SR10_SR24 */
+	 {
+	  0x03, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x10, 0x2c,
+	  0x59, 0x02, 0x00, 0x00, 0x00, 0x0F, 0x0F, 0x00,
+	  0xC4, 0x30, 0x02, 0x01, 0x01,
+	  },
+	 /* reg_SR30_SR75 */
+	 {
+	  0xAA, 0x03, 0x20, 0x89, 0xC0, 0xAA, 0xAA, 0xAA,
+	  0xAA, 0xAA, 0xAA, 0xAA, 0x00, 0x00, 0x03, 0xFF,
+	  0x00, 0xFC, 0x00, 0x00, 0x20, 0x38, 0x00, 0xFC,
+	  0x20, 0x0C, 0x44, 0x20, 0x00, 0x00, 0x00, 0xAA,
+	  0x06, 0x68, 0xA7, 0x7F, 0x83, 0x24, 0xFF, 0x03,
+	  0x00, 0x60, 0x59, 0xAA, 0xAA, 0x00, 0x00, 0xAA,
+	  0x01, 0x80, 0xFF, 0x1A, 0x1A, 0x00, 0x03, 0x00,
+	  0x50, 0x03, 0x0D, 0x02, 0x12, 0x82, 0x09, 0x02,
+	  0x04, 0x45, 0x30, 0x0C, 0x40, 0x20,
+	  },
+	 /* reg_SR80_SR93 */
+	 {
+	  0xFF, 0x07, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xAA,
+	  0xF7, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xAA, 0xAA,
+	  0x00, 0x00, 0x00, 0x00,
+	  },
+	 /* reg_SRA0_SRAF */
+	 {
+	  0x00, 0xFB, 0x9F, 0x01, 0x00, 0xED, 0xED, 0xED,
+	  0x7B, 0xFB, 0xFF, 0xFF, 0x97, 0xEF, 0xBF, 0xDF,
+	  },
+	 /* reg_GR00_GR08 */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
+	  0xFF,
+	  },
+	 /* reg_AR00_AR14 */
+	 {
+	  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+	  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
+	  0x41, 0x11, 0x0F, 0x13, 0x00,
+	  },
+	 /* reg_CR00_CR18 */
+	 {
+	  0xA3, 0x7F, 0x7F, 0x00, 0x85, 0x16, 0x24, 0xF5,
+	  0x00, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0x03, 0x09, 0xFF, 0x80, 0x40, 0xFF, 0x00, 0xE3,
+	  0xFF,
+	  },
+	 /* reg_CR30_CR4D */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x02, 0x20,
+	  0x00, 0x00, 0x00, 0x40, 0x00, 0xFF, 0xBF, 0xFF,
+	  0xA3, 0x7F, 0x00, 0x86, 0x15, 0x24, 0xFF, 0x00,
+	  0x01, 0x07, 0xE5, 0x20, 0x7F, 0xFF,
+	  },
+	 /* reg_CR90_CRA7 */
+	 {
+	  0x55, 0xD9, 0x5D, 0xE1, 0x86, 0x1B, 0x8E, 0x26,
+	  0xDA, 0x8D, 0xDE, 0x94, 0x00, 0x00, 0x18, 0x00,
+	  0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x15, 0x03,
+	  },
+	 },
+	/* mode#7 640 x 480 24Bpp 60Hz */
+	{
+	 DISPLAY_640x480x24,
+	 /* reg_MISC */
+	 0xE3,
+	 /* reg_SR00_SR04 */
+	 {
+	  0x03, 0x01, 0x0F, 0x00, 0x0E,
+	  },
+	 /* reg_SR10_SR24 */
+	 {
+	  0xFF, 0xBE, 0xEF, 0xFF, 0x00, 0x0E, 0x17, 0xe2,
+	  0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0xC4, 0x30, 0x02, 0x01, 0x01,
+	  },
+	 /* reg_SR30_SR75 */
+	 {
+	  0x32, 0x03, 0xA0, 0x09, 0xC0, 0x32, 0x32, 0x32,
+	  0x32, 0x32, 0x32, 0x32, 0x00, 0x00, 0x03, 0xFF,
+	  0x00, 0xFC, 0x00, 0x00, 0x20, 0x18, 0x00, 0xFC,
+	  0x20, 0x0C, 0x44, 0x20, 0x00, 0x32, 0x32, 0x32,
+	  0x04, 0x24, 0x63, 0x4F, 0x52, 0x0B, 0xDF, 0xEA,
+	  0x04, 0x50, 0x19, 0x32, 0x32, 0x00, 0x00, 0x32,
+	  0x01, 0x80, 0x7E, 0x1A, 0x1A, 0x00, 0x00, 0x00,
+	  0x50, 0x03, 0x74, 0x14, 0x07, 0x82, 0x07, 0x04,
+	  0x00, 0x45, 0x30, 0x30, 0x40, 0x30,
+	  },
+	 /* reg_SR80_SR93 */
+	 {
+	  0xFF, 0x07, 0x00, 0x6F, 0x7F, 0x7F, 0xFF, 0x32,
+	  0xF7, 0x00, 0x00, 0x00, 0xEF, 0xFF, 0x32, 0x32,
+	  0x00, 0x00, 0x00, 0x00,
+	  },
+	 /* reg_SRA0_SRAF */
+	 {
+	  0x00, 0xFF, 0xBF, 0xFF, 0xFF, 0xED, 0xED, 0xED,
+	  0x7B, 0xFF, 0xFF, 0xFF, 0xBF, 0xEF, 0xFF, 0xDF,
+	  },
+	 /* reg_GR00_GR08 */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
+	  0xFF,
+	  },
+	 /* reg_AR00_AR14 */
+	 {
+	  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+	  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
+	  0x41, 0x00, 0x0F, 0x00, 0x00,
+	  },
+	 /* reg_CR00_CR18 */
+	 {
+	  0x5F, 0x4F, 0x4F, 0x00, 0x53, 0x1F, 0x0B, 0x3E,
+	  0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0xEA, 0x0C, 0xDF, 0x50, 0x40, 0xDF, 0x00, 0xE3,
+	  0xFF,
+	  },
+	 /* reg_CR30_CR4D */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x55, 0x03, 0x20,
+	  0x00, 0x00, 0x00, 0x40, 0x00, 0xE7, 0xFF, 0xFD,
+	  0x5F, 0x4F, 0x00, 0x54, 0x00, 0x0B, 0xDF, 0x00,
+	  0xEA, 0x0C, 0x2E, 0x00, 0x4F, 0xDF,
+	  },
+	 /* reg_CR90_CRA7 */
+	 {
+	  0x56, 0xDD, 0x5E, 0xEA, 0x87, 0x44, 0x8F, 0x55,
+	  0x0A, 0x8F, 0x55, 0x0A, 0x00, 0x00, 0x18, 0x00,
+	  0x11, 0x10, 0x0B, 0x0A, 0x0A, 0x0A, 0x0A, 0x00,
+	  },
+	 },
+	/* mode#8 800 x 600 24Bpp 60Hz */
+	{
+	 DISPLAY_800x600x24,
+	 /* reg_MISC */
+	 0x2B,
+	 /* reg_SR00_SR04 */
+	 {
+	  0x03, 0x01, 0x0F, 0x03, 0x0E,
+	  },
+	 /* reg_SR10_SR24 */
+	 {
+	  0xFF, 0xBE, 0xEE, 0xFF, 0x00, 0x0E, 0x17, 0xe2,
+	  0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0xC4, 0x30, 0x02, 0x01, 0x01,
+	  },
+	 /* reg_SR30_SR75 */
+	 {
+	  0x36, 0x03, 0x20, 0x09, 0xC0, 0x36, 0x36, 0x36,
+	  0x36, 0x36, 0x36, 0x36, 0x00, 0x00, 0x03, 0xFF,
+	  0x00, 0xFC, 0x00, 0x00, 0x20, 0x18, 0x00, 0xFC,
+	  0x20, 0x0C, 0x44, 0x20, 0x00, 0x36, 0x36, 0x36,
+	  0x04, 0x48, 0x83, 0x63, 0x68, 0x72, 0x57, 0x58,
+	  0x04, 0x55, 0x59, 0x36, 0x36, 0x00, 0x00, 0x36,
+	  0x01, 0x80, 0x7E, 0x1A, 0x1A, 0x00, 0x00, 0x00,
+	  0x50, 0x03, 0x74, 0x14, 0x1C, 0x85, 0x35, 0x13,
+	  0x02, 0x45, 0x30, 0x30, 0x40, 0x20,
+	  },
+	 /* reg_SR80_SR93 */
+	 {
+	  0xFF, 0x07, 0x00, 0x6F, 0x7F, 0x7F, 0xFF, 0x36,
+	  0xF7, 0x00, 0x00, 0x00, 0xEF, 0xFF, 0x36, 0x36,
+	  0x00, 0x00, 0x00, 0x00,
+	  },
+	 /* reg_SRA0_SRAF */
+	 {
+	  0x00, 0xFF, 0xBF, 0xFF, 0xFF, 0xED, 0xED, 0xED,
+	  0x7B, 0xFF, 0xFF, 0xFF, 0xBF, 0xEF, 0xBF, 0xDF,
+	  },
+	 /* reg_GR00_GR08 */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
+	  0xFF,
+	  },
+	 /* reg_AR00_AR14 */
+	 {
+	  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+	  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
+	  0x41, 0x00, 0x0F, 0x00, 0x00,
+	  },
+	 /* reg_CR00_CR18 */
+	 {
+	  0x7F, 0x63, 0x63, 0x00, 0x68, 0x18, 0x72, 0xF0,
+	  0x00, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0x58, 0x0C, 0x57, 0x64, 0x40, 0x57, 0x00, 0xE3,
+	  0xFF,
+	  },
+	 /* reg_CR30_CR4D */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x03, 0x20,
+	  0x00, 0x00, 0x00, 0x40, 0x00, 0xE7, 0xBF, 0xFD,
+	  0x7F, 0x63, 0x00, 0x69, 0x18, 0x72, 0x57, 0x00,
+	  0x58, 0x0C, 0xE0, 0x20, 0x63, 0x57,
+	  },
+	 /* reg_CR90_CRA7 */
+	 {
+	  0x56, 0x4B, 0x5E, 0x55, 0x86, 0x9D, 0x8E, 0xAA,
+	  0xDB, 0x2A, 0xDF, 0x33, 0x00, 0x00, 0x18, 0x00,
+	  0x20, 0x1F, 0x1A, 0x19, 0x0F, 0x0F, 0x0F, 0x00,
+	  },
+	 },
+	/* mode#9 400 x 232 16Bpp 60Hz */
+	{
+	 DISPLAY_LCD_400x232x16,
+	 /* reg_MISC */
+	 0x2B,
+	 /* reg_SR00_SR04 */
+	 {
+	  0x03, 0x01, 0x0F, 0x03, 0x0E,
+	  },
+	 /* reg_SR10_SR24 */
+	 {
+	  0x03, 0x00, 0x00, 0x00, 0x00, 0x08, 0x10, 0x2C,
+	  0x59, 0x00, 0x00, 0x00, 0x00, 0x0F, 0x0F, 0x00,
+	  0x84, 0x00, 0x02, 0x00, 0x31,
+	  },
+	 /* reg_SR30_SR75 */
+	 {
+	  0xB7, 0x43, 0x98, 0x01, 0xC0, 0xB7, 0xB7, 0xB7,
+	  0xB7, 0xB7, 0xB7, 0xB7, 0x00, 0x00, 0x85, 0x2C,
+	  0xC0, 0xE1, 0x00, 0x00, 0x40, 0xF0, 0x80, 0xC4,
+	  0x40, 0x3C, 0xA1, 0x40, 0x00, 0x00, 0x01, 0xB7,
+	  0x02, 0x24, 0xD9, 0xC7, 0xCC, 0x31, 0x2C, 0x2D,
+	  0x07, 0x57, 0x19, 0xB7, 0xB7, 0x00, 0x00, 0xB7,
+	  0x01, 0x00, 0xFF, 0x1A, 0x1A, 0x01, 0x03, 0x00,
+	  0xD4, 0x07, 0x0D, 0x02, 0x23, 0x3F, 0x35, 0x13,
+	  0x83, 0xDD, 0x02, 0x0C, 0x05, 0x00,
+	  },
+	 /* reg_SR80_SR93 */
+	 {
+	  0xFF, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x09, 0xB7,
+	  0x48, 0x00, 0x36, 0x00, 0xFF, 0x00, 0xB7, 0xB7,
+	  0x00, 0x00, 0x00, 0x00,
+	  },
+	 /* reg_SRA0_SRAF */
+	 {
+	  0x00, 0xFF, 0xBF, 0xFF, 0xFF, 0xED, 0xED, 0xED,
+	  0x7B, 0xFF, 0xFF, 0xFF, 0xBF, 0xEF, 0xBF, 0xDF,
+	  },
+	 /* reg_GR00_GR08 */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
+	  0xFF,
+	  },
+	 /* reg_AR00_AR14 */
+	 {
+	  0x00, 0x02, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+	  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
+	  0x10, 0x00, 0x12, 0x00, 0x04,
+	  },
+	 /* reg_CR00_CR18 */
+	 {
+	  0x3B, 0x31, 0x31, 0x00, 0x3A, 0x00, 0x06, 0x11,
+	  0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  0xF1, 0x85, 0xE9, 0x32, 0x40, 0xE9, 0x00, 0xEB,
+	  0xFF,
+	  },
+	 /* reg_CR30_CR4D */
+	 {
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x88, 0x02, 0x10,
+	  0x00, 0x00, 0x00, 0x40, 0x00, 0x20, 0x00, 0x00,
+	  0x3B, 0x31, 0x00, 0x3A, 0x00, 0x06, 0xEA, 0x00,
+	  0xF2, 0x05, 0x01, 0x00, 0x31, 0xE9,
+	  },
+	 /* reg_CR90_CRA7 */
+	 {
+	  0x56, 0x4B, 0x5E, 0x55, 0x86, 0x9D, 0x8E, 0xAA,
+	  0xDB, 0x2A, 0xDF, 0x33, 0xFF, 0xFF, 0x1B, 0x00,
+	  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	  },
+	 },
+};
+
+#endif				/* __SMI_REGS_H__ */

--=-GzVKVITUotwBchgfD2st--


From geert@linux-m68k.org Tue May 31 14:46:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 14:46:35 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:55721 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225785AbVEaNqU>;
	Tue, 31 May 2005 14:46:20 +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 j4VDkEEe010341;
	Tue, 31 May 2005 15:46:16 +0200 (MEST)
Date:	Tue, 31 May 2005 15:45:48 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Sergey Podstavin <spodstavin@ru.mvista.com>
cc:	adaplas@pol.net, linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] A video driver for Lynx3DM on NEC VR5701-SG2 Board.
In-Reply-To: <1117546071.5564.20.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.62.0505311537560.15699@numbat.sonytel.be>
References: <1117546071.5564.20.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8028
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 31 May 2005, Sergey Podstavin wrote:
> Attached is a video driver for Lynx3DM SM722, Silicon Motion Inc. It was
> designed for NEC VR5701-SG2 Board, MIPS-CPU Vr5701. Please review it.

> --- linux_save/drivers/video/Kconfig	2005-05-19 16:08:32.000000000 +0400
> +++ linux_mips/drivers/video/Kconfig	2005-05-31 17:00:36.000000000 +0400
> @@ -1027,6 +1027,25 @@ config FB_ATY_GX
>  	  is at
>  	  <http://support.ati.com/products/pc/mach64/graphics_xpression.html>.
>  
> +config FB_SM
> +	tristate "Silicon Motion SM722 support"
> +	depends on FB && PCI
> +	help
> +	  SM722
> +
> +choice
> +	prompt "Display size"
> +	depends on FB_SM
> +	default DISPLAY_640x480
> +
> +config DISPLAY_640x480
> +	bool "640x480"
> +
> +config DISPLAY_1024x768
> +	bool "1024x768"

Why do you need DISPLAY_640x480 and DISPLAY_1024x768?

> --- linux_save/drivers/video/smi/smi_base.c	1970-01-01 03:00:00.000000000 +0300
> +++ linux_mips/drivers/video/smi/smi_base.c	2005-05-31 17:00:36.000000000 +0400
> @@ -0,0 +1,532 @@
> +/*
> + * drivers/video/smi/smi_base.c
> + *
> + * LynxEM+/EM4+(Silicon Motion Inc.) fb driver	for VR5701-SG2
> + *
> + * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
> + *
> + * 2005 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +
> +#include <linux/config.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/mm.h>
> +#include <linux/selection.h>
> +#include <linux/tty.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/fb.h>
> +#include <linux/init.h>
> +#include <linux/pci.h>
> +#include <linux/console.h>
> +#include "../console/fbcon.h"
> +#include "smifb.h"
> +#include "smi_hw.h"
> +
> +/*
> + * Card Identification
> + *
> + */
> +static struct pci_device_id smifb_pci_tbl[] __devinitdata = {
> +	{PCI_VENDOR_ID_SMI, PCI_DEVICE_ID_SMI_LYNX_EM_PLUS,
> +	 PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},	/* Lynx EM+/EM4+ */
> +	{PCI_VENDOR_ID_SMI, PCI_DEVICE_ID_SMI_LYNX_3DM,
> +	 PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},	/* Lynx 3DM/3DM+/3DM4+ */
> +	{0,}			/* terminate list */
> +};
> +
> +MODULE_DEVICE_TABLE(pci, smifb_pci_tbl);
> +
> +/*
> + *
> + * global variables
> + *
> + */
> +
> +#ifdef CONFIG_DISPLAY_1024x768
> +/* 1024x768, 16bpp, 60Hz */
> +static struct fb_var_screeninfo smifb_default_var = {
> +      xres:1024,
> +      yres:768,

Please use C99-style struct initializers, e.g.

	.xres = 1024,

> +/*
> + * VGA registers
> + *
> + */
> +static void Unlock(struct smifb_info *sinfo)
> +{
> +	pr_debug("Unlock");
> +	regSR_write(sinfo->mmio, 0x33, regSR_read(sinfo->mmio, 0x33) & 0x20);
> +}
> +
> +static void Lock(struct smifb_info *sinfo)
> +{
> +	pr_debug("Lock");
> +}

Hmm, Lock() doesn't do anything, while Unlock() does?

> diff -Naurp --exclude=CVS linux_save/drivers/video/smi/smifb.h linux_mips/drivers/video/smi/smifb.h
> --- linux_save/drivers/video/smi/smifb.h	1970-01-01 03:00:00.000000000 +0300
> +++ linux_mips/drivers/video/smi/smifb.h	2005-05-31 17:00:36.000000000 +0400
> @@ -0,0 +1,89 @@
> +/*
> + * drivers/video/smi/smifb.h
> + *
> + * LynxEM+/EM4+(Silicon Motion Inc.) fb driver	for VR5701-SG2
> + *
> + * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
> + *
> + * 2005 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +
> +#ifndef __SMIFB_H__
> +#define __SMIFB_H__
> +
> +#define FBCON_HAS_CFB16

Relic from 2.4?

> +struct smifb_info;
> +struct smifb_info {

You don't need a forward declaration just before the real declaration.

> +	/* PCI base physical addresses */
> +	unsigned long fb_base_phys;	/* physical Frame Buffer base address                  */
> +	unsigned long dpr_base_phys;	/* physical Drawing Processor base address             */
> +	unsigned long vpr_base_phys;	/* physical Video Processor base address               */
> +	unsigned long cpr_base_phys;	/* physical Capture Processor base address             */
> +	unsigned long mmio_base_phys;	/* physical MMIO spase (VGA + SMI regs ?) base address */
> +	unsigned long dpport_base_phys;	/* physical Drawing Processor Data Port base address   */
> +	int dpport_size;	/* size of Drawin Processor Data Port memory space     */
> +
> +	/* PCI base virtual addresses */
> +	caddr_t base;		/* address of base */
        unsigned long?

> +	caddr_t fb_base;	/* address of frame buffer base */
> +	caddr_t dpr;		/* Drawing Processor Registers  */
> +	caddr_t vpr;		/* Video Processor Registers    */
> +	caddr_t cpr;		/* Capture Processor Registers  */
> +	caddr_t mmio;		/* Memory Mapped I/O Port       */
> +	caddr_t dpport;		/* Drawing Processor Data       */

Etc.

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 spodstavin@ru.mvista.com Tue May 31 15:24:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 15:25:10 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:53135 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225792AbVEaOYz>; Tue, 31 May 2005 15:24:55 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4VEOmt06157;
	Tue, 31 May 2005 19:24:48 +0500
Subject: [PATCH] An IDE driver for NEC VR5701-SG2 Board
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	B.Zolnierkiewicz@elka.pw.edu.pl
Cc:	linux-mips <linux-mips@linux-mips.org>
Content-Type: multipart/mixed; boundary="=-1QT6C8KMS2odChJmeBIX"
Organization: MontaVista
Date:	Tue, 31 May 2005 18:25:06 +0400
Message-Id: <1117549506.5564.25.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8029
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Bartlomiej!

Attached is an IDE driver for NEC VR5701-SG2 Board. It works on CPU
VR5701 internal IDE interface. The IDE has the same vendor ID and Device
ID for internal USB interface, so the driver check class ID. Please
review it.

Best wishes,
Sergey Podstavin.

--=-1QT6C8KMS2odChJmeBIX
Content-Disposition: attachment; filename=community_mips_nec_vr5701_ide.patch
Content-Type: text/x-patch; name=community_mips_nec_vr5701_ide.patch; charset=UTF-8
Content-Transfer-Encoding: 7bit

diff -Naurp --exclude=CVS linux_save/drivers/ide/Kconfig linux_mips/drivers/ide/Kconfig
--- linux_save/drivers/ide/Kconfig	2005-03-18 20:37:18.000000000 +0300
+++ linux_mips/drivers/ide/Kconfig	2005-05-31 17:58:08.000000000 +0400
@@ -835,6 +835,12 @@ config BLK_DEV_GAYLE
 	  Note that you also have to enable Zorro bus support if you want to
 	  use Gayle IDE interfaces on the Zorro expansion bus.
 
+config BLK_DEV_NEC_VR5701_SG2
+	bool "NEC VR5701-SG2 IDE interface support"
+	depends on TCUBE
+	help
+	  This is the IDE driver for the NEC VR5701-SG2 IDE interface. 
+
 config BLK_DEV_IDEDOUBLER
 	bool "Amiga IDE Doubler support (EXPERIMENTAL)"
 	depends on BLK_DEV_GAYLE && EXPERIMENTAL
diff -Naurp --exclude=CVS linux_save/drivers/ide/pci/Makefile linux_mips/drivers/ide/pci/Makefile
--- linux_save/drivers/ide/pci/Makefile	2005-02-13 23:16:22.000000000 +0300
+++ linux_mips/drivers/ide/pci/Makefile	2005-05-31 17:58:08.000000000 +0400
@@ -27,6 +27,7 @@ obj-$(CONFIG_BLK_DEV_SLC90E66)		+= slc90
 obj-$(CONFIG_BLK_DEV_TRIFLEX)		+= triflex.o
 obj-$(CONFIG_BLK_DEV_TRM290)		+= trm290.o
 obj-$(CONFIG_BLK_DEV_VIA82CXXX)		+= via82cxxx.o
+obj-$(CONFIG_BLK_DEV_NEC_VR5701_SG2)	+= nec_vr5701_sg2.o
 
 # Must appear at the end of the block
 obj-$(CONFIG_BLK_DEV_GENERIC)          += generic.o
diff -Naurp --exclude=CVS linux_save/drivers/ide/pci/nec_vr5701_sg2.c linux_mips/drivers/ide/pci/nec_vr5701_sg2.c
--- linux_save/drivers/ide/pci/nec_vr5701_sg2.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/drivers/ide/pci/nec_vr5701_sg2.c	2005-05-31 17:58:08.000000000 +0400
@@ -0,0 +1,111 @@
+/*
+ * drivers/ide/pci/nec_vr5701_sg2.c
+ *
+ * NEC VR5701-SG2 IDE controller driver
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/config.h>
+#include <linux/pci.h>
+#include <linux/ide.h>
+#include <linux/config.h>
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/timer.h>
+#include <linux/mm.h>
+#include <linux/ioport.h>
+#include <linux/blkdev.h>
+#include <linux/hdreg.h>
+#include <linux/pci.h>
+#include <linux/ide.h>
+#include <linux/init.h>
+#include <asm/io.h>
+
+static unsigned int __init init_chipset_nec_vr5701(struct pci_dev *dev,
+						   const char *name)
+{
+	return 0;
+}
+
+static void __init init_hwif_nec_vr5701(ide_hwif_t * hwif)
+{
+	if (!(hwif->dma_base))
+		return;
+
+	hwif->atapi_dma = 1;
+	hwif->ultra_mask = 0x7f;
+	hwif->mwdma_mask = 0x07;
+	hwif->swdma_mask = 0x07;
+
+	if (!noautodma)
+		hwif->autodma = 1;
+	hwif->drives[0].autodma = hwif->autodma;
+	hwif->drives[1].autodma = hwif->autodma;
+}
+
+static ide_pci_device_t nec_vr5701_chipset __devinitdata = {
+	.name = "NEC VR5701",
+	.init_chipset = init_chipset_nec_vr5701,
+	.init_hwif = init_hwif_nec_vr5701,
+	.channels = 2,
+	.autodma = AUTODMA,
+	.bootable = ON_BOARD,
+};
+
+static int __devinit nec_vr5701_init_one(struct pci_dev *dev,
+					 const struct pci_device_id *id)
+{
+	ide_pci_device_t *d = &nec_vr5701_chipset;
+	u16 command;
+
+	if (dev->vendor == PCI_VENDOR_ID_NEC &&
+	    dev->device == PCI_DEVICE_ID_NEC_USB_AND_IDE &&
+	    dev->class == 0x0c0310)
+		return 1;
+	udelay(100);
+	pci_enable_device(dev);
+	*(volatile unsigned char *)0xb9001010 = 6;
+	asm("sync");
+	udelay(100);
+
+	pci_read_config_word(dev, PCI_COMMAND, &command);
+	if (!(command & PCI_COMMAND_IO)) {
+		printk(KERN_INFO "Skipping disabled %s IDE controller.\n",
+		       d->name);
+		return 1;
+	}
+	ide_setup_pci_device(dev, d);
+	return 0;
+}
+
+static struct pci_device_id nec_vr5701_pci_tbl[] = {
+	{PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB_AND_IDE, PCI_ANY_ID,
+	 PCI_ANY_ID, 0x010185, 0xffffff, 0},
+	{0,},
+};
+
+MODULE_DEVICE_TABLE(pci, nec_vr5701_pci_tbl);
+
+static struct pci_driver driver = {
+	.name = "nec_vr5701_IDE",
+	.id_table = nec_vr5701_pci_tbl,
+	.probe = nec_vr5701_init_one,
+};
+
+static int nec_vr5701_ide_init(void)
+{
+	return ide_pci_register_driver(&driver);
+}
+
+module_init(nec_vr5701_ide_init);
+
+MODULE_AUTHOR("Sergey Podstavin");
+MODULE_DESCRIPTION("PCI driver module for nec vr5701 IDE");
+MODULE_LICENSE("GPL");

--=-1QT6C8KMS2odChJmeBIX--


From macro@linux-mips.org Tue May 31 15:29:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 15:29:42 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:14857 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225795AbVEaO31>; Tue, 31 May 2005 15:29:27 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id A207FF5977; Tue, 31 May 2005 16:29:22 +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 26914-04; Tue, 31 May 2005 16:29:22 +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 5A96CE1CA5; Tue, 31 May 2005 16:29:22 +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 j4VESWiH008835;
	Tue, 31 May 2005 16:28:32 +0200
Date:	Tue, 31 May 2005 15:28:39 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	maxim@mox.ru
Cc:	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
In-Reply-To: <6097c4905052703152b50f717@mail.gmail.com>
Message-ID: <Pine.LNX.4.61L.0505311520140.30850@blysk.ds.pg.gda.pl>
References: <6097c4905052609326a4c1232@mail.gmail.com> 
 <20050526170603.GA13272@nevyn.them.org>  <Pine.LNX.4.61L.0505261815330.29423@blysk.ds.pg.gda.pl>
 <6097c4905052703152b50f717@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/901/Tue May 31 15:33:04 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8030
X-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, 27 May 2005, Maxim Osipov wrote:

> Do anyone have a clue what is happening? AFAIK, some people already
> had success building glibc for mips64. Probably I miss something?

 Please feel free to have a look at packages available at my site -- the 
setup may seem a little bit odd (n64 is used as the default format and 
actually the only one supported), but if you are after general setup, 
patches, etc. it is still relevant; just ignore the odd stuff.  Binary 
packages have been built with GCC 4.0.0, so probably the sources + patches 
are going to work with older tools as well.  You may consider using 
binutils 2.16, though (in general, not to solve your particular problem).

  Maciej

From spodstavin@ru.mvista.com Tue May 31 15:50:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 15:51:00 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:62095 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225796AbVEaOuq>; Tue, 31 May 2005 15:50:46 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4VEoct06771;
	Tue, 31 May 2005 19:50:38 +0500
Subject: [PATCH]  PCI IDs for NEC VR5701-SG2 Board
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	mj@ucw.cz
Cc:	linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista
Date:	Tue, 31 May 2005 18:50:56 +0400
Message-Id: <1117551056.5564.36.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Content-Transfer-Encoding: 7bit
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8031
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips

Hi Martin!

Attached is PCI IDs for NEC VR5701-SG2 Board. The CPU is Vr5701, Vr5500
core. The CPU has internal IDE interface and USB interface with the same
device ID - 0000. The internal AC97 interface uses the same device ID as
VRC5477 system controller for AC97 interface. The board works with
Lynx3DM SM722 video adapter, Silicon Motion Inc. The Silicon Motion IDs
had been added to drivers/pci/pci.ids early. Please review it.

Best wishes,
Sergey Podstavin.


From spodstavin@ru.mvista.com Tue May 31 15:52:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 15:52:22 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:63375 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225799AbVEaOwH>; Tue, 31 May 2005 15:52:07 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4VEq5t06824;
	Tue, 31 May 2005 19:52:05 +0500
Subject: [PATCH]  PCI IDs for NEC VR5701-SG2 Board
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	mj@ucw.cz
Cc:	linux-mips <linux-mips@linux-mips.org>
Content-Type: multipart/mixed; boundary="=-0N0Ff8XkG2RMe9cCGPzZ"
Organization: MontaVista
Date:	Tue, 31 May 2005 18:52:23 +0400
Message-Id: <1117551143.5564.39.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8032
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Martin!

Attached is PCI IDs for NEC VR5701-SG2 Board. The CPU is Vr5701, Vr5500
core. The CPU has internal IDE interface and USB interface with the same
device ID - 0000. The internal AC97 interface uses the same device ID as
VRC5477 system controller for AC97 interface. The board works with
Lynx3DM SM722 video adapter, Silicon Motion Inc. The Silicon Motion IDs
had been added to drivers/pci/pci.ids early. Please review it.

Best wishes,
Sergey Podstavin.



--=-0N0Ff8XkG2RMe9cCGPzZ
Content-Disposition: attachment; filename=community_mips_nec_vr5701_pci_id.patch
Content-Type: text/x-patch; name=community_mips_nec_vr5701_pci_id.patch; charset=UTF-8
Content-Transfer-Encoding: 7bit

diff -Naurp --exclude=CVS linux_save/drivers/pci/pci.ids linux_mips/drivers/pci/pci.ids
--- linux_save/drivers/pci/pci.ids	2005-04-08 22:58:21.000000000 +0400
+++ linux_mips/drivers/pci/pci.ids	2005-05-31 18:38:16.000000000 +0400
@@ -1612,7 +1612,7 @@
 	6057  MiroVideo DC10/DC30+
 1032  Compaq
 1033  NEC Corporation
-	0000  Vr4181A USB Host or Function Control Unit
+	0000  Vr4181A USB Host or IDE Controller
 	0001  PCI to 486-like bus Bridge
 	0002  PCI to VL98 Bridge
 	0003  ATM Controller
@@ -1653,7 +1653,7 @@
 		1033 8014  RCV56ACF 56k Voice Modem
 	009b  Vrc5476
 	00a5  VRC4173
-	00a6  VRC5477 AC97
+	00a6  VRC5477 or VR5701 AC97 Controller
 	00cd  IEEE 1394 [OrangeLink] Host Controller
 		12ee 8011  Root hub
 	00ce  IEEE 1394 Host Controller
diff -Naurp --exclude=CVS linux_save/include/linux/pci_ids.h linux_mips/include/linux/pci_ids.h
--- linux_save/include/linux/pci_ids.h	2005-05-26 13:12:48.000000000 +0400
+++ linux_mips/include/linux/pci_ids.h	2005-05-31 18:38:16.000000000 +0400
@@ -582,6 +582,7 @@
 #define PCI_DEVICE_ID_MIRO_DC30PLUS	0xd801
 
 #define PCI_VENDOR_ID_NEC		0x1033
+#define PCI_DEVICE_ID_NEC_USB_AND_IDE	0x0000 /* USB 1.1 or IDE Controller*/
 #define PCI_DEVICE_ID_NEC_CBUS_1	0x0001 /* PCI-Cbus Bridge */
 #define PCI_DEVICE_ID_NEC_LOCAL		0x0002 /* Local Bridge */
 #define PCI_DEVICE_ID_NEC_ATM		0x0003 /* ATM LAN Controller */
@@ -1787,6 +1788,11 @@
 #define PCI_DEVICE_ID_SATSAGEM_PCR2101	0x5352
 #define PCI_DEVICE_ID_SATSAGEM_TELSATTURBO 0x5a4b
 
+#define PCI_VENDOR_ID_SMI		0x126f
+#define PCI_DEVICE_ID_SMI_LYNX_EM	0x0710
+#define PCI_DEVICE_ID_SMI_LYNX_EM_PLUS	0x0712
+#define PCI_DEVICE_ID_SMI_LYNX_3DM	0x0720
+
 #define PCI_VENDOR_ID_HUGHES		0x1273
 #define PCI_DEVICE_ID_HUGHES_DIRECPC	0x0002
 

--=-0N0Ff8XkG2RMe9cCGPzZ--


From macro@linux-mips.org Tue May 31 15:57:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 15:57:26 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:22536 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225796AbVEaO5M>; Tue, 31 May 2005 15:57:12 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 6DFDBF5978; Tue, 31 May 2005 16:57:02 +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 16840-07; Tue, 31 May 2005 16:57:02 +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 39E20F5977; Tue, 31 May 2005 16:57:02 +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 j4VEv5LN010300;
	Tue, 31 May 2005 16:57:05 +0200
Date:	Tue, 31 May 2005 15:57:13 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Michael Belamina <belamina1@yahoo.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: 64 bit kernel for BCM1250
In-Reply-To: <20050526185931.58037.qmail@web32510.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61L.0505311544130.30850@blysk.ds.pg.gda.pl>
References: <20050526185931.58037.qmail@web32510.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/901/Tue May 31 15:33:04 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: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8033
X-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 Thu, 26 May 2005, Michael Belamina wrote:

> I have tried the patch on kernel version 2.4.28 and it
> seems that the fix is not working for this kernel
> version. I used gcc version 2.95.4 and it is working. 

 Hmm, you may need additional fixes...  How about just switching to 2.6?  
Currently 2.4 is over 4 years old and it shouldn't be used for new 
development.

> 1. What is the best way to translate 32 bit ioctl
> codes to 64 bit?

 Use arch/mips64/kernel/ioctl32.c, but in 2.6 there may be a generic 
solution available.

> 2. How 64 bit kernel space buffers will  be used by a
> 32 bit application (using mmap)? 

 As usual.  Except you can't get more than 2GB of them.

> 3.What is the maximum usable ram out of 2GB I will
> have if I am using a 32 bit application and 64 bit
> kernel and the kernel is allocating the buffers using
> __get_free_pages (I need the buffers for DMA - and I
> need them to be physically continuous)?

 2GB minus what's used by Linux for other purposes.  Physically 
contiguous?  That sounds like a problem (and broken hardware)...

  Maciej

From spodstavin@ru.mvista.com Tue May 31 16:25:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 16:26:03 +0100 (BST)
Received: from RT-soft-1.Moscow.itn.ru ([IPv6:::ffff:80.240.96.90]:22928 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225804AbVEaPZh>; Tue, 31 May 2005 16:25:37 +0100
Received: from 192.168.1.226 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j4VFPZt07898;
	Tue, 31 May 2005 20:25:35 +0500
Subject: [PATCH] A LSP for NEC VR5701-SG2 Board.
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	ralf@linux-mips.org
Cc:	linux-mips <linux-mips@linux-mips.org>
Content-Type: multipart/mixed; boundary="=-mspiNCIP3YakTU/JruAA"
Organization: MontaVista
Date:	Tue, 31 May 2005 19:25:53 +0400
Message-Id: <1117553153.5564.44.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8034
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips


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

Hi Ralf!

Attached is a LSP core for NEC VR5701-SG2 Board. The CPU is Vr5701,
Vr5500 core. The drivers have been sent separately. Please review it.

Best wishes,
Sergey Podstavin.
  

--=-mspiNCIP3YakTU/JruAA
Content-Disposition: attachment; filename=community_mips_nec_vr5701_lsp.patch
Content-Type: text/x-patch; name=community_mips_nec_vr5701_lsp.patch; charset=UTF-8
Content-Transfer-Encoding: 7bit

diff -Naurp --exclude=CVS linux_save/arch/mips/Kconfig linux_mips/arch/mips/Kconfig
--- linux_save/arch/mips/Kconfig	2005-03-18 20:36:52.000000000 +0300
+++ linux_mips/arch/mips/Kconfig	2005-05-31 19:03:47.812560480 +0400
@@ -431,6 +431,18 @@ config DDB5477
 	  Features : kernel debugging, serial terminal, NFS root fs, on-board
 	  ether port USB, AC97, PCI, etc.
 
+config TCUBE
+	bool "Support for NEC VR5701-SG2"
+	select IRQ_CPU
+	select HW_HAS_PCI
+	select DMA_NONCOHERENT
+	select NO_SPINLOCK
+	help
+	  This enables support for the VR5500 - based NEC VR5701-SG2
+	  evaluation board.
+
+
+
 config NEC_OSPREY
 	bool "Support for NEC Osprey board"
 	select DMA_NONCOHERENT
@@ -964,6 +976,11 @@ config CPU_R5432
 	select CPU_SUPPORTS_32BIT_KERNEL
 	select CPU_SUPPORTS_64BIT_KERNEL
 
+config CPU_R5500
+	bool "R5500"
+	help
+	  MIPS Technologies Vr5500 - series processors.
+
 config CPU_R6000
 	bool "R6000"
 	depends on EXPERIMENTAL
diff -Naurp --exclude=CVS linux_save/arch/mips/kernel/cpu-probe.c linux_mips/arch/mips/kernel/cpu-probe.c
--- linux_save/arch/mips/kernel/cpu-probe.c	2005-05-25 17:32:49.000000000 +0400
+++ linux_mips/arch/mips/kernel/cpu-probe.c	2005-05-31 19:03:47.822558960 +0400
@@ -93,6 +93,7 @@ static inline void check_wait(void)
 	case CPU_R4650:
 	case CPU_R4700:
 	case CPU_R5000:
+	case CPU_R5500:
 	case CPU_NEVADA:
 	case CPU_RM7000:
 	case CPU_RM9000:
diff -Naurp --exclude=CVS linux_save/arch/mips/kernel/Makefile linux_mips/arch/mips/kernel/Makefile
--- linux_save/arch/mips/kernel/Makefile	2005-02-21 13:45:09.000000000 +0300
+++ linux_mips/arch/mips/kernel/Makefile	2005-05-31 19:03:47.823558808 +0400
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_R4300)		+= r4k_fpu.o r4
 obj-$(CONFIG_CPU_R4X00)		+= r4k_fpu.o r4k_switch.o
 obj-$(CONFIG_CPU_R5000)		+= r4k_fpu.o r4k_switch.o
 obj-$(CONFIG_CPU_R5432)		+= r4k_fpu.o r4k_switch.o
+obj-$(CONFIG_CPU_R5500)		+= r4k_fpu.o r4k_switch.o
 obj-$(CONFIG_CPU_R8000)		+= r4k_fpu.o r4k_switch.o
 obj-$(CONFIG_CPU_RM7000)	+= r4k_fpu.o r4k_switch.o
 obj-$(CONFIG_CPU_RM9000)	+= r4k_fpu.o r4k_switch.o
diff -Naurp --exclude=CVS linux_save/arch/mips/lib-32/Makefile linux_mips/arch/mips/lib-32/Makefile
--- linux_save/arch/mips/lib-32/Makefile	2004-06-08 16:03:09.000000000 +0400
+++ linux_mips/arch/mips/lib-32/Makefile	2005-05-31 19:03:47.827558200 +0400
@@ -13,6 +13,7 @@ obj-$(CONFIG_CPU_R4300)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R4X00)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R5000)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R5432)		+= dump_tlb.o
+obj-$(CONFIG_CPU_R5500)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R6000)		+=
 obj-$(CONFIG_CPU_R8000)		+=
 obj-$(CONFIG_CPU_RM7000)	+= dump_tlb.o
diff -Naurp --exclude=CVS linux_save/arch/mips/lib-64/Makefile linux_mips/arch/mips/lib-64/Makefile
--- linux_save/arch/mips/lib-64/Makefile	2004-06-08 16:03:09.000000000 +0400
+++ linux_mips/arch/mips/lib-64/Makefile	2005-05-31 19:03:47.897547560 +0400
@@ -13,6 +13,7 @@ obj-$(CONFIG_CPU_R4300)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R4X00)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R5000)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R5432)		+= dump_tlb.o
+obj-$(CONFIG_CPU_R5500)		+= dump_tlb.o
 obj-$(CONFIG_CPU_R6000)		+=
 obj-$(CONFIG_CPU_R8000)		+=
 obj-$(CONFIG_CPU_RM7000)	+= dump_tlb.o
diff -Naurp --exclude=CVS linux_save/arch/mips/Makefile linux_mips/arch/mips/Makefile
--- linux_save/arch/mips/Makefile	2005-05-19 18:45:12.000000000 +0400
+++ linux_mips/arch/mips/Makefile	2005-05-31 19:03:47.944540416 +0400
@@ -194,6 +194,10 @@ cflags-$(CONFIG_CPU_R5432)	+= \
 			$(call set_gccflags,r5400,mips4,r5000,mips4,mips2) \
 			-Wa,--trap
 
+cflags-$(CONFIG_CPU_R5500)	+= \
+			$(call set_gccflags,mips32,mips4,r5000,mips4,mips2) \
+			-Wa,--trap
+
 cflags-$(CONFIG_CPU_NEVADA)	+= \
 			$(call set_gccflags,rm5200,mips4,r5000,mips4,mips2) \
 			-Wa,--trap
@@ -490,6 +494,13 @@ load-$(CONFIG_DDB5476)		+= 0xffffffff800
 core-$(CONFIG_DDB5477)		+= arch/mips/ddb5xxx/ddb5477/
 load-$(CONFIG_DDB5477)		+= 0xffffffff80100000
 
+#
+# NEC TCUBE
+#
+core-$(CONFIG_TCUBE)		+= arch/mips/vr5701/common/
+core-$(CONFIG_TCUBE)		+= arch/mips/vr5701/tcube/
+load-$(CONFIG_TCUBE)		+= 0xffffffff80080000
+
 core-$(CONFIG_LASAT)		+= arch/mips/lasat/
 cflags-$(CONFIG_LASAT)		+= -Iinclude/asm-mips/mach-lasat
 load-$(CONFIG_LASAT)		+= 0xffffffff80000000
diff -Naurp --exclude=CVS linux_save/arch/mips/mm/Makefile linux_mips/arch/mips/mm/Makefile
--- linux_save/arch/mips/mm/Makefile	2005-01-12 03:10:42.000000000 +0300
+++ linux_mips/arch/mips/mm/Makefile	2005-05-31 19:03:47.997532360 +0400
@@ -18,6 +18,7 @@ obj-$(CONFIG_CPU_R4300)		+= c-r4k.o cex-
 obj-$(CONFIG_CPU_R4X00)		+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
 obj-$(CONFIG_CPU_R5000)		+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
 obj-$(CONFIG_CPU_R5432)		+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
+obj-$(CONFIG_CPU_R5500)		+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
 obj-$(CONFIG_CPU_R8000)		+= c-r4k.o cex-gen.o pg-r4k.o tlb-r8k.o
 obj-$(CONFIG_CPU_RM7000)	+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
 obj-$(CONFIG_CPU_RM9000)	+= c-r4k.o cex-gen.o pg-r4k.o tlb-r4k.o
diff -Naurp --exclude=CVS linux_save/arch/mips/mm/tlbex.c linux_mips/arch/mips/mm/tlbex.c
--- linux_save/arch/mips/mm/tlbex.c	2005-04-28 12:52:57.000000000 +0400
+++ linux_mips/arch/mips/mm/tlbex.c	2005-05-31 19:03:48.007530840 +0400
@@ -784,6 +784,7 @@ static __init void __attribute__((unused
 	case CPU_R5000:
 	case CPU_R5000A:
 	case CPU_NEVADA:
+	case CPU_R5500:
 		i_nop(p);
 		i_tlbp(p);
 		break;
@@ -832,6 +833,7 @@ static __init void build_tlb_write_entry
 	case CPU_R4600:
 	case CPU_R4700:
 	case CPU_R5000:
+	case CPU_R5500:             
 	case CPU_R5000A:
 	case CPU_5KC:
 	case CPU_TX49XX:
diff -Naurp --exclude=CVS linux_save/arch/mips/pci/Makefile linux_mips/arch/mips/pci/Makefile
--- linux_save/arch/mips/pci/Makefile	2004-12-18 05:23:50.000000000 +0300
+++ linux_mips/arch/mips/pci/Makefile	2005-05-31 19:03:48.013529928 +0400
@@ -52,3 +52,4 @@ obj-$(CONFIG_TOSHIBA_JMR3927)	+= fixup-j
 obj-$(CONFIG_TOSHIBA_RBTX4927)	+= fixup-rbtx4927.o ops-tx4927.o
 obj-$(CONFIG_VICTOR_MPC30X)	+= fixup-mpc30x.o
 obj-$(CONFIG_ZAO_CAPCELLA)	+= fixup-capcella.o
+obj-$(CONFIG_TCUBE)		+= pci-tcube.o ops-tcube.o
diff -Naurp --exclude=CVS linux_save/arch/mips/pci/ops-tcube.c linux_mips/arch/mips/pci/ops-tcube.c
--- linux_save/arch/mips/pci/ops-tcube.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/pci/ops-tcube.c	2005-05-31 19:03:48.018529168 +0400
@@ -0,0 +1,267 @@
+/*
+ * arch/mips/pci/ops-tcube.c
+ *
+ * A config access for PCI controllers on NEC VR5701-SG2 
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/pci.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <asm/addrspace.h>
+#include <asm/debug.h>
+#include <asm/tcube.h>
+
+/*
+ * config_swap structure records what set of pdar/pmr are used
+ * to access pci config space.  It also provides a place hold the
+ * original values for future restoring.
+ */
+struct pci_config_swap {
+	u32 pdar;
+	u32 pmr;
+	u32 config_base;
+	u32 config_size;
+	u32 pdar_backup;
+	u32 pmr_backup;
+};
+
+/*
+ * On VR5701-SG2, we have two sets of swap registers, for ext PCI and IOPCI.
+ */
+struct pci_config_swap ext_pci_swap = {
+	PADR_EPCIW0,
+	EPCI_INIT0,
+	0x10000000,
+	0x08000000
+};
+struct pci_config_swap io_pci_swap = {
+	PADR_IOPCIW0,
+	IPCI_INIT0,
+	0x18800000,
+	0x00800000
+};
+
+/*
+ * access config space
+ */
+static inline u32 ddb_access_config_base(struct pci_config_swap *swap, u32 bus,	/* 0 means top level bus */
+					 u32 slot_num)
+{
+	u32 pci_addr = 0;
+	u32 pciinit_offset = 0;
+	u32 virt_addr;
+	u32 option;
+
+	/* minimum pdar (window) size is 2MB */
+	db_assert(swap->config_size >= (2 << 20));
+	db_assert(slot_num < (1 << 5));
+	db_assert(bus < (1 << 8));
+
+	/* backup registers */
+	swap->pdar_backup = ddb_in32(swap->pdar);
+	swap->pmr_backup = ddb_in32(swap->pmr);
+
+	/* set the pdar (pci window) register */
+	ddb_set_pdar(swap->pdar, swap->config_base, swap->config_size, 32,	/* 32 bit wide */
+		     0,		/* not on local memory bus */
+		     0);	/* not visible from PCI bus (N/A) */
+
+	/*
+	 * calcuate the absolute pci config addr;
+	 * according to the spec, we start scanning from adr:11 (0x800)
+	 */
+	if (bus == 0) {
+		/* type 0 config */
+		pci_addr = 0x800 << slot_num;
+	} else {
+		/* type 1 config */
+		pci_addr = (bus << 16) | (slot_num << 11);
+	}
+
+	/*
+	 * if pci_addr is less than pci config window size,  we set
+	 * pciinit_offset to 0 and adjust the virt_address.
+	 * Otherwise we will try to adjust pciinit_offset.
+	 */
+	if (pci_addr < swap->config_size) {
+		virt_addr = KSEG1ADDR(swap->config_base + pci_addr);
+		pciinit_offset = 0;
+	} else {
+		db_assert((pci_addr & (swap->config_size - 1)) == 0);
+		virt_addr = KSEG1ADDR(swap->config_base);
+		pciinit_offset = pci_addr;
+	}
+
+	/* set the pmr register */
+	option = DDB_PCI_ACCESS_32;
+	if (bus != 0)
+		option |= DDB_PCI_CFGTYPE1;
+
+	ddb_out32(swap->pmr,
+		  (DDB_PCICMD_CFG << 1) | (pciinit_offset & 0xffe00000) |
+		  option);
+	ddb_out32(swap->pmr + 4, 0);
+
+	return virt_addr;
+}
+
+static inline void ddb_close_config_base(struct pci_config_swap *swap)
+{
+	ddb_out32(swap->pdar, swap->pdar_backup);
+	ddb_out32(swap->pmr, swap->pmr_backup);
+}
+
+static int read_config_dword(struct pci_config_swap *swap,
+			     struct pci_bus *bus, u32 devfn, u32 where,
+			     u32 * val)
+{
+	u32 bus_num, slot_num, func_num;
+	u32 base;
+
+	db_assert((where & 3) == 0);
+	db_assert(where < (1 << 8));
+
+	/* check if the bus is top-level */
+	if (bus->parent != NULL) {
+		bus_num = bus->number;
+		db_assert(bus_num != 0);
+	} else {
+		bus_num = 0;
+	}
+	slot_num = PCI_SLOT(devfn);
+	func_num = PCI_FUNC(devfn);
+	base = ddb_access_config_base(swap, bus_num, slot_num);
+	*val = *(volatile u32 *)(base + (func_num << 8) + where);
+	ddb_close_config_base(swap);
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int read_config_word(struct pci_config_swap *swap,
+			    struct pci_bus *bus, u32 devfn, u32 where,
+			    u16 * val)
+{
+	int status;
+	u32 result;
+
+	db_assert((where & 1) == 0);
+
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
+	if (where & 2)
+		result >>= 16;
+	*val = result & 0xffff;
+	return status;
+}
+
+static int read_config_byte(struct pci_config_swap *swap,
+			    struct pci_bus *bus, u32 devfn, u32 where, u8 * val)
+{
+	int status;
+	u32 result;
+
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
+	if (where & 1)
+		result >>= 8;
+	if (where & 2)
+		result >>= 16;
+	*val = result & 0xff;
+
+	return status;
+}
+
+static int write_config_dword(struct pci_config_swap *swap,
+			      struct pci_bus *bus, u32 devfn, u32 where,
+			      u32 val)
+{
+	u32 bus_num, slot_num, func_num;
+	u32 base;
+
+	db_assert((where & 3) == 0);
+	db_assert(where < (1 << 8));
+
+	/* check if the bus is top-level */
+	if (bus->parent != NULL) {
+		bus_num = bus->number;
+		db_assert(bus_num != 0);
+	} else {
+		bus_num = 0;
+	}
+
+	slot_num = PCI_SLOT(devfn);
+	func_num = PCI_FUNC(devfn);
+	base = ddb_access_config_base(swap, bus_num, slot_num);
+	*(volatile u32 *)(base + (func_num << 8) + where) = val;
+	ddb_close_config_base(swap);
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int write_config_word(struct pci_config_swap *swap,
+			     struct pci_bus *bus, u32 devfn, u32 where, u16 val)
+{
+	int status, shift = 0;
+	u32 result;
+
+	db_assert((where & 1) == 0);
+
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
+	if (status != PCIBIOS_SUCCESSFUL)
+		return status;
+
+	if (where & 2)
+		shift += 16;
+	result &= ~(0xffff << shift);
+	result |= val << shift;
+	return write_config_dword(swap, bus, devfn, where & ~3, result);
+}
+
+static int write_config_byte(struct pci_config_swap *swap,
+			     struct pci_bus *bus, u32 devfn, u32 where, u8 val)
+{
+	int status, shift = 0;
+	u32 result;
+
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
+	if (status != PCIBIOS_SUCCESSFUL)
+		return status;
+
+	if (where & 2)
+		shift += 16;
+	if (where & 1)
+		shift += 8;
+	result &= ~(0xff << shift);
+	result |= val << shift;
+	return write_config_dword(swap, bus, devfn, where & ~3, result);
+}
+
+#define        MAKE_PCI_OPS(prefix, rw, pciswap, star) \
+static int prefix##_##rw##_config(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 star val) \
+{ \
+	if (size == 1) \
+     		return rw##_config_byte(pciswap, bus, devfn, where, (u8 star)val); \
+	else if (size == 2) \
+     		return rw##_config_word(pciswap, bus, devfn, where, (u16 star)val); \
+	/* Size must be 4 */ \
+     	return rw##_config_dword(pciswap, bus, devfn, where, val); \
+}
+
+MAKE_PCI_OPS(extpci, read, &ext_pci_swap, *)
+    MAKE_PCI_OPS(extpci, write, &ext_pci_swap,)
+
+    MAKE_PCI_OPS(iopci, read, &io_pci_swap, *)
+    MAKE_PCI_OPS(iopci, write, &io_pci_swap,)
+
+struct pci_ops VR5701_ext_pci_ops = {
+	.read = extpci_read_config,
+	.write = extpci_write_config
+};
+
+struct pci_ops VR5701_io_pci_ops = {
+	.read = iopci_read_config,
+	.write = iopci_write_config
+};
diff -Naurp --exclude=CVS linux_save/arch/mips/pci/pci-tcube.c linux_mips/arch/mips/pci/pci-tcube.c
--- linux_save/arch/mips/pci/pci-tcube.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/pci/pci-tcube.c	2005-05-31 19:03:48.018529168 +0400
@@ -0,0 +1,123 @@
+/*
+ * arch/mips/pci/pci-tcube.c
+ *
+ * A code for PCI controllers on NEC VR5701-SG2 
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/pci.h>
+#include <asm/bootinfo.h>
+#include <asm/debug.h>
+#include <asm/byteorder.h>
+#include <asm/tcube.h>
+
+static struct resource extpci_io_resource = {
+	"ext pci IO space",
+	0x00001000,
+	0x007FFFFF,
+	IORESOURCE_IO
+};
+
+static struct resource extpci_mem_resource = {
+	"ext pci memory space",
+	0x10000000,
+	0x17FFFFFF,
+	IORESOURCE_MEM
+};
+
+static struct resource iopci_io_resource = {
+	"io pci IO space",
+	0x01000000,
+	0x017FFFFF,
+	IORESOURCE_IO
+};
+
+static struct resource iopci_mem_resource = {
+	"io pci memory space",
+	0x18800000,
+	0x18FFFFFF,
+	IORESOURCE_MEM
+};
+
+struct pci_controller VR5701_ext_controller = {
+	.pci_ops = &VR5701_ext_pci_ops,
+	.io_resource = &extpci_io_resource,
+	.mem_resource = &extpci_mem_resource
+};
+
+struct pci_controller VR5701_io_controller = {
+	.pci_ops = &VR5701_io_pci_ops,
+	.io_resource = &iopci_io_resource,
+	.mem_resource = &iopci_mem_resource
+};
+
+int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
+{
+	int slot_num;
+	int k;
+
+	slot_num = PCI_SLOT(dev->devfn);
+
+	if (dev->bus->number == 0) {	/* EPCI */
+		switch (slot_num) {
+		case 25 - 11:	/* INTC# */
+			k = NUM_5701_IRQS + 2;
+			break;
+		case 26 - 11:	/* INTB# */
+			k = NUM_5701_IRQS + 1;
+			break;
+		case 27 - 11:	/* INTA# */
+			k = NUM_5701_IRQS + 0;
+			break;
+		}
+	} else {		/* IPCI */
+		switch (slot_num) {
+		case 29 - 11:	/* INTC# */
+			k = NUM_5701_IRQS + NUM_5701_EPCI_IRQ + 2;
+			break;
+		case 30 - 11:	/* INTB# */
+			k = NUM_5701_IRQS + NUM_5701_EPCI_IRQ + 1;
+			break;
+		case 31 - 11:	/* INTA# */
+			k = NUM_5701_IRQS + NUM_5701_EPCI_IRQ + 0;
+			break;
+		}
+	}
+	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, k);
+	dev->irq = k + 8;
+	return dev->irq;
+}
+
+void ddb_pci_reset_bus(void)
+{
+	u32 temp;
+
+	temp = ddb_in32(EPCI_CTRLH);
+	temp |= 0x80000000;
+	ddb_out32(EPCI_CTRLH, temp);
+	udelay(100);
+	temp &= ~0xc0000000;
+	ddb_out32(EPCI_CTRLH, temp);
+
+	temp = ddb_in32(IPCI_CTRLH);
+	temp |= 0x80000000;
+	ddb_out32(IPCI_CTRLH, temp);
+	udelay(100);
+	temp &= ~0xc0000000;
+	ddb_out32(IPCI_CTRLH, temp);
+}
+
+/* Do platform specific device initialization at pci_enable_device() time */
+int pcibios_plat_dev_init(struct pci_dev *dev)
+{
+	return 0;
+}
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/common/Makefile linux_mips/arch/mips/vr5701/common/Makefile
--- linux_save/arch/mips/vr5701/common/Makefile	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/common/Makefile	2005-05-31 19:03:48.019529016 +0400
@@ -0,0 +1,5 @@
+#
+# Makefile for the common code of NEC VR5701 board
+#
+
+obj-y += nec_vrxxxx.o prom.o rtc_rx5c348.o
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/common/nec_vrxxxx.c linux_mips/arch/mips/vr5701/common/nec_vrxxxx.c
--- linux_save/arch/mips/vr5701/common/nec_vrxxxx.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/common/nec_vrxxxx.c	2005-05-31 19:03:48.063522328 +0400
@@ -0,0 +1,119 @@
+/*
+ * arch/mips/vr5701/common/nec_vrxxxx.c
+ *
+ * A code for low-level routines on NEC VR5701-SG2 
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/config.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <asm/tcube.h>
+
+u32
+ddb_calc_pdar(u32 phys, u32 size, int width, int on_memory_bus, int pci_visible)
+{
+	u32 maskbits;
+	u32 widthbits;
+
+	switch (size) {
+	case 0x80000000:	/* 2 GB */
+		maskbits = 5;
+		break;
+	case 0x40000000:	/* 1 GB */
+		maskbits = 6;
+		break;
+	case 0x20000000:	/* 512 MB */
+		maskbits = 7;
+		break;
+	case 0x10000000:	/* 256 MB */
+		maskbits = 8;
+		break;
+	case 0x08000000:	/* 128 MB */
+		maskbits = 9;
+		break;
+	case 0x04000000:	/* 64 MB */
+		maskbits = 10;
+		break;
+	case 0x02000000:	/* 32 MB */
+		maskbits = 11;
+		break;
+	case 0x01000000:	/* 16 MB */
+		maskbits = 12;
+		break;
+	case 0x00800000:	/* 8 MB */
+		maskbits = 13;
+		break;
+	case 0x00400000:	/* 4 MB */
+		maskbits = 14;
+		break;
+	case 0x00200000:	/* 2 MB */
+		maskbits = 15;
+		break;
+	case 0:		/* OFF */
+		maskbits = 0;
+		break;
+	default:
+		panic("VR5701_set_pdar: unsupported size %p", (void *)size);
+	}
+	switch (width) {
+	case 8:
+		widthbits = 0;
+		break;
+	case 16:
+		widthbits = 1;
+		break;
+	case 32:
+		widthbits = 2;
+		break;
+	case 64:
+		widthbits = 3;
+		break;
+	default:
+		panic("VR5701_set_pdar: unsupported width %d", width);
+	}
+
+	return maskbits | (on_memory_bus ? 0x10 : 0) |
+	    (pci_visible ? 0x20 : 0) | (widthbits << 6) | (phys & 0xffe00000);
+}
+
+void
+ddb_set_pdar(u32 pdar, u32 phys, u32 size, int width,
+	     int on_memory_bus, int pci_visible)
+{
+	u32 temp = ddb_calc_pdar(phys, size, width, on_memory_bus, pci_visible);
+	ddb_out32(pdar, temp);
+	ddb_out32(pdar + 4, 0);
+	ddb_in32(pdar);
+	ddb_in32(pdar + 4);
+}
+
+/*
+ * routines that mess with PCIINITx registers
+ */
+
+void ddb_set_pmr(u32 pmr, u32 type, u32 addr, u32 options)
+{
+	switch (type) {
+	case DDB_PCICMD_IACK:	/* PCI Interrupt Acknowledge */
+	case DDB_PCICMD_IO:	/* PCI I/O Space */
+	case DDB_PCICMD_MEM:	/* PCI Memory Space */
+	case DDB_PCICMD_CFG:	/* PCI Configuration Space */
+		break;
+	default:
+		panic("VR5701_set_pmr: invalid type %d", type);
+	}
+	ddb_out32(pmr, (type << 1) | (addr & 0xffe00000) | options);
+	ddb_out32(pmr + 4, 0);
+}
+
+void ddb_set_bar(u32 bar, u32 phys, int prefetchable)
+{
+	ddb_out32(bar, (phys & 0xffe00000) | (!!prefetchable << 3));
+	ddb_out32(bar + 4, 0);
+}
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/common/prom.c linux_mips/arch/mips/vr5701/common/prom.c
--- linux_save/arch/mips/vr5701/common/prom.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/common/prom.c	2005-05-31 19:03:48.064522176 +0400
@@ -0,0 +1,53 @@
+/*
+ * arch/mips/vr5701/common/prom.c
+ *
+ * A code for prom routines on NEC VR5701-SG2 
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/sched.h>
+#include <linux/bootmem.h>
+#include <asm/addrspace.h>
+#include <asm/bootinfo.h>
+#include <asm/debug.h>
+#include <asm/tcube.h>
+
+const char *get_system_type(void)
+{
+	return "NEC VR5701-SG2";
+}
+
+void __init prom_init(void)
+{
+	int i;
+	int argc = fw_arg0;
+	char **arg = (char **)fw_arg1;
+
+	/* if user passes kernel args, ignore the default one */
+	if (argc > 1)
+		arcs_cmdline[0] = '\0';
+
+	/* arg[0] is "g", the rest is boot parameters */
+	for (i = 1; i < argc; i++) {
+		if (strlen(arcs_cmdline) + strlen(arg[i] + 1)
+		    >= sizeof(arcs_cmdline))
+			break;
+		strcat(arcs_cmdline, arg[i]);
+		strcat(arcs_cmdline, " ");
+	}
+	mips_machgroup = MACH_GROUP_SHIMA;
+	mips_machtype = MACH_SHIMA_TCUBE;
+	add_memory_region(0, TCUBE_SDRAM_SIZE, BOOT_MEM_RAM);
+}
+
+void __init prom_free_prom_memory(void)
+{
+}
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/common/rtc_rx5c348.c linux_mips/arch/mips/vr5701/common/rtc_rx5c348.c
--- linux_save/arch/mips/vr5701/common/rtc_rx5c348.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/common/rtc_rx5c348.c	2005-05-31 19:03:48.065522024 +0400
@@ -0,0 +1,184 @@
+/*
+ * arch/mips/vr5701/common/rtc_rx5c348.c Version 0.02 April 11, 2005
+ *
+ * A Real Time Clock interface for Linux on NEC VR5701-SG2
+ * (RICOH Co., Ltd., Rx5C348B)
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/time.h>
+#include <linux/kernel.h>
+#include <linux/bcd.h>
+
+#include <asm/time.h>
+#include <asm/addrspace.h>
+#include <asm/delay.h>
+#include <asm/debug.h>
+#include <asm/tcube.h>
+
+#undef  DEBUG
+#define RTC_DELAY
+
+void static rtc_set_ce(u32 val)
+{
+	pr_debug("rtc_set_ce(%d)\n", val);
+	reg_set32(GIU_PIO0, GPIO_4_CE, val ? SET_32_BIT : 0);
+#ifdef RTC_DELAY
+	__delay(100000);
+#endif
+}
+
+void static rtc_write_burst(int adr, unsigned char *data, int dataLen)
+{
+	int i;
+	for (i = 0; i < dataLen; i++)
+		pr_debug(" rtc_write_burst : data=%08x\n", data[i]);
+	pr_debug(" rtc_write_burst : adr=0x%02x\n", adr);
+	csi1_reset();
+	while (io_in32(CSI1_MODE) & CSIn_MODE_CSOT) ;
+	reg_set32(CSI1_MODE, CSIn_MODE_AUTO, SET_32_BIT);
+	reg_set32(CSI1_MODE, CSIn_MODE_TRMD, SET_32_BIT);
+	io_out32(CSI1_INT, CSIn_INT_CSIEND);
+	rtc_set_ce(1);
+
+	pr_debug(" rtc_write_burst : CSI1_MODE=%08x\n", io_in32(CSI1_MODE));
+	pr_debug(" rtc_write_burst : CSI1_CNT=%08x\n", io_in32(CSI1_CNT));
+	io_out32(CSI1_SOTBF, ((adr << 4) | 0x00));
+
+	for (i = 0; i < dataLen; i++) {
+		io_out32(CSI1_SOTB, data[i]);
+		while (!(io_in32(CSI1_INT) & CSIn_INT_CSIEND)) ;
+		io_out32(CSI1_INT, CSIn_INT_CSIEND);
+	}
+	while (io_in32(CSI1_MODE) & CSIn_MODE_CSOT) ;
+	rtc_set_ce(0);
+}
+
+void static rtc_read_burst(int adr, unsigned char *data, int dataLen)
+{
+	int i;
+	pr_debug(" rtc_read_burst : adr=0x%02x\n", adr);
+	csi1_reset();
+	while (io_in32(CSI1_MODE) & CSIn_MODE_CSOT) ;
+	reg_set32(CSI1_MODE, CSIn_MODE_AUTO, CLR_32_BIT);
+	reg_set32(CSI1_MODE, CSIn_MODE_TRMD, SET_32_BIT);
+	io_out32(CSI1_INT, CSIn_INT_CSIEND);
+	rtc_set_ce(1);
+
+	pr_debug(" rtc_read_burst : CSI1_MODE=%08x\n", io_in32(CSI1_MODE));
+	pr_debug(" rtc_read_burst : CSI1_CNT=%08x\n", io_in32(CSI1_CNT));
+	io_out32(CSI1_SOTB, (((adr & 0xf) << 4) | 0x04));
+	while (!(io_in32(CSI1_INT) & CSIn_INT_CSIEND)) ;
+
+	while (io_in32(CSI1_MODE) & CSIn_MODE_CSOT) ;
+	reg_set32(CSI1_MODE, CSIn_MODE_AUTO, SET_32_BIT);
+	reg_set32(CSI1_MODE, CSIn_MODE_TRMD, CLR_32_BIT);
+	io_out32(CSI1_INT, CSIn_INT_CSIEND);
+
+	udelay(50);
+	pr_debug(" rtc_read_burst : CSI1_MODE=%08x\n", io_in32(CSI1_MODE));
+	pr_debug(" rtc_read_burst : CSI1_CNT=%08x\n", io_in32(CSI1_CNT));
+	io_in32(CSI1_SIRB);	/* dummy read */
+
+	for (i = 0; i < dataLen; i++) {
+		while (!(io_in32(CSI1_INT) & CSIn_INT_CSIEND)) ;
+		io_out32(CSI1_INT, CSIn_INT_CSIEND);
+		data[i] = io_in32(CSI1_SIRB);
+	}
+	while (io_in32(CSI1_MODE) & CSIn_MODE_CSOT) ;
+	rtc_set_ce(0);
+	for (i = 0; i < dataLen; i++)
+		pr_debug(" rtc_read_burst : data=%08x\n", data[i]);
+}
+
+static unsigned long rtc_ricoh_rx5c348_get_time(void)
+{
+	u8 date[7];
+	unsigned int year, month, day, hour, minute, second;
+
+	rtc_read_burst(0, date, sizeof(date));
+
+	year = BCD2BIN(date[6]) + (date[5] & 0x80 ? 2000 : 1900);
+	month = BCD2BIN(date[5] & 0x1f);
+	day = BCD2BIN(date[4]);
+	hour = BCD2BIN(date[2]);
+	minute = BCD2BIN(date[1]);
+	second = BCD2BIN(date[0]);
+
+	pr_debug(KERN_INFO
+		 "rtc_ricoh_rx5c348_get_time: %d/%02d/%02d %02d:%02d:%02d\n",
+		 year, month, day, hour, minute, second);
+	return mktime(year, month, day, hour, minute, second);
+}
+
+static int rtc_ricoh_rx5c348_set_time(unsigned long t)
+{
+	u8 date[7];
+	struct rtc_time tm;
+
+	to_tm(t, &tm);
+	date[0] = BIN2BCD(tm.tm_sec);
+	date[1] = BIN2BCD(tm.tm_min);
+	date[2] = BIN2BCD(tm.tm_hour);
+	date[4] = BIN2BCD(tm.tm_mday);
+	date[5] = BIN2BCD(tm.tm_mon + 1) + (tm.tm_year > 1999 ? 0x80 : 0);
+	date[6] =
+	    BIN2BCD(tm.tm_year > 1999 ? tm.tm_year - 2000 : tm.tm_year - 1900);
+
+	rtc_write_burst(0, date, 3);
+	rtc_write_burst(4, date + 4, 3);
+
+	pr_debug(KERN_INFO
+		 "rtc_ricoh_rx5c348_set_time:t=%ld %d/%02d/%02d %02d:%02d:%02d\n",
+		 t, tm.tm_year, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour,
+		 tm.tm_min, tm.tm_sec);
+	return 0;
+}
+
+static int __devinit rtc_ricoh_rx5c348_init(void)
+{
+	unsigned char data;
+	/* CSI1 reset  */
+	io_set16(PIB_RESET, 0x40, 0xffff);
+	__delay(10000);
+	io_set16(PIB_RESET, 0x40, 0x0000);
+
+	/* set GPIO3 , GPIO4 */
+	reg_set32(GIU_FUNCSEL0, (GPIO_4_CE | GPIO_3_INTR), SET_32_BIT);
+	/* clear GPIO25 , GPIO26 , GPIO27 */
+	reg_set32(GIU_FUNCSEL0, GPIO_CSI1_PIN, CLR_32_BIT);
+	/* make GPIO4 output */
+	reg_set32(GIU_DIR0, GPIO_4_CE, SET_32_BIT);
+	/* make GPIO3 input  */
+	reg_set32(GIU_DIR0, GPIO_3_INTR, CLR_32_BIT);
+
+	csi1_reset();
+
+	rtc_read_burst(0x0e, &data, 1);
+	if ((data & 0x20) == 0) {	/* 24 hour */
+		data |= 0x20;
+		rtc_write_burst(0x0e, &data, 1);
+#ifdef RTC_DELAY
+		__delay(10000);
+#endif
+	}
+
+	/* set the function pointers */
+	rtc_get_time = rtc_ricoh_rx5c348_get_time;
+	rtc_set_time = rtc_ricoh_rx5c348_set_time;
+	return 0;
+}
+
+module_init(rtc_ricoh_rx5c348_init);
+
+MODULE_AUTHOR("Sergey Podstavin");
+MODULE_DESCRIPTION("Real Time Clock interface for Linux on T-Cube VR5701");
+MODULE_LICENSE("GPL");
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/tcube/int-handler.S linux_mips/arch/mips/vr5701/tcube/int-handler.S
--- linux_save/arch/mips/vr5701/tcube/int-handler.S	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/tcube/int-handler.S	2005-05-31 19:03:48.065522024 +0400
@@ -0,0 +1,78 @@
+/*
+ * arch/mips/vr5701/tcube/int-handler.S
+ *
+ * First-level interrupt dispatcher for NEC VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#define  __ASSEMBLY__
+#include <linux/config.h>
+#include <asm/asm.h>
+#include <asm/mipsregs.h>
+#include <asm/addrspace.h>
+#include <asm/regdef.h>
+#include <asm/stackframe.h>
+#include <asm/tcube.h>
+
+/*
+ * first level interrupt dispatcher for ocelot board -
+ * We check for the timer first, then check PCI ints A and D.
+ * Then check for serial IRQ and fall through.
+ */
+	.align	5
+	NESTED(tcube_handle_int, PT_SIZE, sp)
+	SAVE_ALL
+	CLI
+	.set	at
+	.set	noreorder
+	mfc0	t0, CP0_CAUSE  
+	mfc0	t2, CP0_STATUS
+
+	and	t0, t2
+       
+	andi	t1, t0, STATUSF_IP7	/* cpu timer */
+	bnez	t1, ll_cputimer_irq
+	andi	t1, t0, (STATUSF_IP2 | STATUSF_IP3 | STATUSF_IP4 | STATUSF_IP5 | STATUSF_IP6 ) 
+	bnez	t1, ll_tcube_irq
+	andi	t1, t0, STATUSF_IP0	/* software int 0 */
+	bnez	t1, ll_cpu_ip0
+	andi	t1, t0, STATUSF_IP1	/* software int 1 */
+	bnez	t1, ll_cpu_ip1
+	nop
+	.set	reorder
+
+	/* wrong alarm or masked ... */
+	j	spurious_interrupt
+	nop
+	END(tcube_handle_int)
+
+	.align	5
+
+ll_tcube_irq:	
+	move	a0, sp
+	jal	tcube_irq_dispatch
+	j	ret_from_irq
+
+ll_cputimer_irq:
+	li	a0, 7
+	move	a1, sp
+	jal	do_IRQ
+	j	ret_from_irq
+
+
+ll_cpu_ip0:	
+	li	a0, 0
+	move	a1, sp
+	jal	do_IRQ
+	j	ret_from_irq
+
+ll_cpu_ip1:	
+	li	a0, 1
+	move	a1, sp
+	jal	do_IRQ
+	j	ret_from_irq
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/tcube/irq.c linux_mips/arch/mips/vr5701/tcube/irq.c
--- linux_save/arch/mips/vr5701/tcube/irq.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/tcube/irq.c	2005-05-31 19:03:48.066521872 +0400
@@ -0,0 +1,146 @@
+/*
+ * arch/mips/vr5701/tcube/irq.c
+ *
+ * The irq setup and misc routines for NEC VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/types.h>
+#include <linux/ptrace.h>
+#include <asm/system.h>
+#include <asm/mipsregs.h>
+#include <asm/debug.h>
+#include <asm/tcube.h>
+/*
+ * IRQ mapping
+ *
+ *  0-7: 8 CPU interrupts
+ *	0 -	software interrupt 0
+ *	1 -	software interrupt 1
+ *	2 -	most Vrc5477 interrupts are routed to this pin
+ *	3 -	(optional) some other interrupts routed to this pin for debugg
+ *	4 -	not used
+ *	5 -	not used
+ *	6 -	not used
+ *	7 -	cpu timer (used by default)
+ *
+ */
+
+void tcube_irq_setup(void)
+{
+	pr_debug("T-Cube irq setup invoked.\n");
+
+	/* by default, we disable all interrupts and route all vr5701
+	 * interrupts to pin 0 (irq 2) */
+	ddb_out32(INT_ROUTE0, 0);
+	ddb_out32(INT_ROUTE1, 0);
+	ddb_out32(INT_ROUTE2, 0);
+	ddb_out32(INT_ROUTE3, 0);
+	ddb_out32(INT_MASK, 0);
+	ddb_out32(INT_CLR, ~0x0);
+
+	clear_c0_status(0xff00);
+	set_c0_status(0x0400);
+
+	ll_vr5701_irq_route(24, 1);
+	ll_vr5701_irq_enable(24);
+	ll_vr5701_irq_route(25, 1);
+	ll_vr5701_irq_enable(25);
+	ll_vr5701_irq_route(28, 1);
+	ll_vr5701_irq_enable(28);
+	ll_vr5701_irq_route(29, 1);
+	ll_vr5701_irq_enable(29);
+	ll_vr5701_irq_route(30, 1);
+	ll_vr5701_irq_enable(30);
+	ll_vr5701_irq_route(31, 1);
+	ll_vr5701_irq_enable(31);
+	set_c0_status(0x0800);
+	set_except_vector(0, tcube_handle_int);
+	/* init all controllers */
+	mips_cpu_irq_init(0);
+	vr5701_irq_init(8);
+}
+
+/*
+ * the first level int-handler will jump here if it is a vr7701 irq
+ */
+
+asmlinkage void tcube_irq_dispatch(struct pt_regs *regs)
+{
+	u32 intStatus;
+	u32 bitmask;
+	u32 i;
+	u32 intPCIStatus;
+	if (ddb_in32(INT1_STAT) != 0) {
+		printk(KERN_CRIT "NMI  = %x\n", ddb_in32(NMI_STAT));
+		printk(KERN_CRIT "INT0 = %x\n", ddb_in32(INT0_STAT));
+		printk(KERN_CRIT "INT1 = %x\n", ddb_in32(INT1_STAT));
+		printk(KERN_CRIT "INT2 = %x\n", ddb_in32(INT2_STAT));
+		printk(KERN_CRIT "INT3 = %x\n", ddb_in32(INT3_STAT));
+		printk(KERN_CRIT "INT4 = %x\n", ddb_in32(INT4_STAT));
+		printk(KERN_CRIT "EPCI_ERR = %x\n", ddb_in32(EPCI_ERR));
+		printk(KERN_CRIT "IPCI_ERR = %x\n", ddb_in32(IPCI_ERR));
+
+		panic("error interrupt has happened.");
+	}
+
+	intStatus = ddb_in32(INT0_STAT);
+
+	if (intStatus & 1 << 6)
+		goto IRQ_EPCI;
+
+	if (intStatus & 1 << 7)
+		goto IRQ_IPCI;
+
+      IRQ_OTHER:
+	for (i = 0, bitmask = 1; i <= NUM_5701_IRQS; bitmask <<= 1, i++) {
+		/* do we need to "and" with the int mask? */
+		if (intStatus & bitmask) {
+			do_IRQ(8 + i, regs);
+		}
+	}
+	return;
+
+      IRQ_EPCI:
+	intStatus &= ~(1 << 6);	/* unset Status flag */
+	intPCIStatus = ddb_in32(EPCI_INTS);
+	for (i = 0, bitmask = 1; i < NUM_5701_EPCI_IRQS; bitmask <<= 1, i++) {
+		if (intPCIStatus & bitmask) {
+			do_IRQ(8 + NUM_5701_IRQS + i, regs);
+		}
+	}
+	if (!intStatus)
+		return;
+
+      IRQ_IPCI:
+	intStatus &= ~(1 << 7);
+	intPCIStatus = ddb_in32(IPCI_INTS);
+	if (!intPCIStatus)
+		goto IRQ_OTHER;
+
+	for (i = 0, bitmask = 1; i < NUM_5701_IPCI_IRQS; bitmask <<= 1, i++) {
+		if (intPCIStatus & bitmask) {
+			do_IRQ(8 + NUM_5701_IRQS + NUM_5701_EPCI_IRQS + i,
+			       regs);
+		}
+	}
+
+	if (!intStatus)
+		return;
+
+	goto IRQ_OTHER;
+}
+
+void __init arch_init_irq(void)
+{
+	/* invoke board-specific irq setup */
+	tcube_irq_setup();
+}
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/tcube/irq_vr5701.c linux_mips/arch/mips/vr5701/tcube/irq_vr5701.c
--- linux_save/arch/mips/vr5701/tcube/irq_vr5701.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/tcube/irq_vr5701.c	2005-05-31 19:03:48.067521720 +0400
@@ -0,0 +1,194 @@
+/*
+ * arch/mips/vr5701/tcube/irq_vr5701.c
+ *
+ * This file defines the irq handler for NEC VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * Vr5701 defines 32 IRQs.
+ *
+ */
+#include <linux/interrupt.h>
+#include <linux/types.h>
+#include <linux/ptrace.h>
+
+#include <asm/debug.h>
+#include <asm/tcube.h>
+
+static int vr5701_irq_base = -1;
+
+void ll_vr5701_irq_disable(int vr5701_irq, int ack);
+
+static void vr5701_irq_enable(unsigned int irq)
+{
+	ll_vr5701_irq_enable(irq - vr5701_irq_base);
+}
+
+static void vr5701_irq_disable(unsigned int irq)
+{
+	ll_vr5701_irq_disable(irq - vr5701_irq_base, 0);
+}
+
+static unsigned int vr5701_irq_startup(unsigned int irq)
+{
+	vr5701_irq_enable(irq);
+	return 0;
+}
+
+static void vr5701_irq_ack(unsigned int irq)
+{
+	unsigned long flags;
+	local_irq_save(flags);
+
+	/* clear the interrupt bit for edge trigger */
+	/* some irqs require the driver to clear the sources */
+	if (irq < vr5701_irq_base + NUM_5701_IRQ) {
+		ddb_out32(INT_CLR, 1 << (irq - vr5701_irq_base));
+	}
+	/* don't need for PCIs, for they are level triger */
+
+	/* disable interrupt - some handler will re-enable the irq
+	 * and if the interrupt is leveled, we will have infinite loop
+	 */
+	ll_vr5701_irq_disable(irq - vr5701_irq_base, 1);
+	local_irq_restore(flags);
+}
+
+static void vr5701_irq_end(unsigned int irq)
+{
+	unsigned long flags;
+	local_irq_save(flags);
+
+	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) {
+		ll_vr5701_irq_enable(irq - vr5701_irq_base);
+	}
+	local_irq_restore(flags);
+}
+
+struct hw_interrupt_type vr5701_irq_type = {
+	"vr5701_irq",
+	vr5701_irq_startup,
+	vr5701_irq_disable,
+	vr5701_irq_enable,
+	vr5701_irq_disable,
+	vr5701_irq_ack,
+	vr5701_irq_end,
+	NULL			/* no affinity stuff for UP */
+};
+
+void vr5701_irq_init(u32 irq_base)
+{
+	extern irq_desc_t irq_desc[];
+	u32 i;
+	vr5701_irq_base = irq_base;
+	for (i = irq_base;
+	     i < irq_base + NUM_5701_IRQ + NUM_EPCI_IRQ + NUM_IPCI_IRQ; i++) {
+		irq_desc[i].status = IRQ_DISABLED;
+		irq_desc[i].action = 0;
+		irq_desc[i].depth = 1;
+		irq_desc[i].handler = &vr5701_irq_type;
+	}
+}
+
+int vr5701_irq_to_irq(int irq)
+{
+	return irq + vr5701_irq_base;
+}
+
+void ll_vr5701_irq_route(int vr5701_irq, int ip)
+{
+	u32 reg_value;
+	u32 reg_bitmask;
+	u32 reg_index;
+
+	if (vr5701_irq >= NUM_5701_IRQ) {
+		if (vr5701_irq >= NUM_5701_IRQ + NUM_EPCI_IRQ) {
+			vr5701_irq = 7;
+		} else {
+			vr5701_irq = 6;
+		}
+	}
+	reg_index = INT_ROUTE0 + vr5701_irq / 8 * 4;
+	reg_value = ddb_in32(reg_index);
+	reg_bitmask = 7 << (vr5701_irq % 8 * 4);
+	reg_value &= ~reg_bitmask;
+	reg_value |= ip << (vr5701_irq % 8 * 4);
+	ddb_out32(reg_index, reg_value);
+}
+
+void ll_vr5701_irq_enable(int vr5701_irq)
+{
+	u16 reg_value;
+	u32 reg_bitmask;
+	unsigned long flags;
+
+	local_irq_save(flags);
+	irq_desc[vr5701_irq_base + vr5701_irq].depth++;
+
+	if (vr5701_irq >= NUM_5701_IRQ) {
+		if (vr5701_irq >= NUM_5701_IRQ + NUM_EPCI_IRQ) {
+			reg_value = ddb_in32(IPCI_INTM);
+			reg_bitmask =
+			    1 << (vr5701_irq - NUM_5701_IRQ - NUM_EPCI_IRQ);
+			ddb_out32(IPCI_INTM, reg_value | reg_bitmask);
+			vr5701_irq = 7;
+		} else {
+			reg_value = ddb_in32(EPCI_INTM);
+			reg_bitmask = 1 << (vr5701_irq - NUM_5701_IRQ);
+			ddb_out32(EPCI_INTM, reg_value | reg_bitmask);
+			vr5701_irq = 6;
+		}
+	}
+	reg_value = ddb_in32(INT_MASK);
+	ddb_out32(INT_MASK, reg_value | (1 << vr5701_irq));
+	local_irq_restore(flags);
+}
+
+void ll_vr5701_irq_disable(int vr5701_irq, int ack)
+{
+	u16 reg_value;
+	u32 udummy;
+	u32 reg_bitmask;
+	unsigned long flags;
+
+	local_irq_save(flags);
+	if (!ack) {
+		irq_desc[vr5701_irq_base + vr5701_irq].depth--;
+		if (irq_desc[vr5701_irq_base + vr5701_irq].depth) {
+			local_irq_restore(flags);
+			return;
+		}
+	}
+
+	if (vr5701_irq >= NUM_5701_IRQ) {
+		if (vr5701_irq >= NUM_5701_IRQ + NUM_EPCI_IRQ) {
+			goto DISABLE_IRQ_IPCI;
+		} else {
+			goto DISABLE_IRQ_EPCI;
+		}
+	}
+	reg_value = ddb_in32(INT_MASK);
+	ddb_out32(INT_MASK, reg_value & ~(1 << vr5701_irq));
+	udummy = ddb_in32(INT_MASK);
+	local_irq_restore(flags);
+	return;
+
+      DISABLE_IRQ_IPCI:
+	reg_value = ddb_in32(IPCI_INTM);
+	reg_bitmask = 1 << (vr5701_irq - NUM_5701_IRQ - NUM_EPCI_IRQ);
+	ddb_out32(IPCI_INTM, reg_value & ~reg_bitmask);
+	local_irq_restore(flags);
+	return;
+
+      DISABLE_IRQ_EPCI:
+	reg_value = ddb_in32(EPCI_INTM);
+	reg_bitmask = 1 << (vr5701_irq - NUM_5701_IRQ);
+	ddb_out32(EPCI_INTM, reg_value & ~reg_bitmask);
+	local_irq_restore(flags);
+}
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/tcube/Makefile linux_mips/arch/mips/vr5701/tcube/Makefile
--- linux_save/arch/mips/vr5701/tcube/Makefile	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/tcube/Makefile	2005-05-31 19:03:48.067521720 +0400
@@ -0,0 +1,7 @@
+#
+# Makefile for the NEC VR5701-SG2 specific kernel interface routines
+# under Linux.
+#
+
+obj-y += setup.o irq.o int-handler.o irq_vr5701.o 
+EXTRA_AFLAGS: = $(CFLAGS)
diff -Naurp --exclude=CVS linux_save/arch/mips/vr5701/tcube/setup.c linux_mips/arch/mips/vr5701/tcube/setup.c
--- linux_save/arch/mips/vr5701/tcube/setup.c	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/arch/mips/vr5701/tcube/setup.c	2005-05-31 19:03:48.068521568 +0400
@@ -0,0 +1,189 @@
+/*
+ * arch/mips/vr5701/tcube/setup.c
+ *
+ * Setup file for NEC VR5701-SG2
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kdev_t.h>
+#include <linux/types.h>
+#include <linux/console.h>
+#include <linux/sched.h>
+#include <linux/pci.h>
+#include <linux/fs.h>		/* for ROOT_DEV */
+#include <linux/ioport.h>
+#include <linux/param.h>	/* for HZ */
+#include <asm/bootinfo.h>
+#include <asm/addrspace.h>
+#include <asm/time.h>
+#include <asm/bcache.h>
+#include <asm/irq.h>
+#include <asm/reboot.h>
+#include <asm/gdb-stub.h>
+#include <asm/debug.h>
+#include <asm/tcube.h>
+
+static void tcube_machine_restart(char *command)
+{
+	static void (*back_to_prom) (void) = (void (*)(void))0xbfc00000;
+	back_to_prom();
+}
+
+static void tcube_machine_halt(void)
+{
+	printk(KERN_CRIT "VR5701-SG2 halted.\n");
+	while (1) ;
+}
+
+static void tcube_machine_power_off(void)
+{
+	printk(KERN_CRIT "VR5701-SG2 halted. Please turn off the power.\n");
+	while (1) ;
+}
+
+static void __init tcube_time_init(void)
+{
+	mips_hpt_frequency = CPU_COUNTER_FREQUENCY;
+}
+
+static void __init tcube_timer_setup(struct irqaction *irq)
+{
+	unsigned int count;
+	irq->flags |= SA_NODELAY;
+
+	/* we are using the cpu counter for timer interrupts */
+	setup_irq(7, irq);
+
+	/* to generate the first timer interrupt */
+	count = read_c0_count();
+	write_c0_compare(count + 10000);
+}
+
+#if defined(CONFIG_BLK_DEV_INITRD)
+extern unsigned long __rd_start, __rd_end, initrd_start, initrd_end;
+#endif
+
+static void chk_init_5701_reg(unsigned long addr, unsigned long data)
+{
+	unsigned long a = ddb_in32(addr);
+
+	if (a != data) {
+		printk(KERN_INFO
+		       "Unexpected 5701 reg : addr = %08lX, expected = %08lX, read = %08lX\n",
+		       addr + VR5701_IO_BASE, data, a);
+	}
+}
+
+static void __init tcube_board_init(void)
+{
+	chk_init_5701_reg(0, 0x1e00008f);
+	chk_init_5701_reg(PADR_SDRAM01, 0x000000a8);
+	chk_init_5701_reg(PADR_LOCALCS0, 0x1f00004c);
+	chk_init_5701_reg(LOCAL_CST0, 0x00088622);
+	chk_init_5701_reg(LOCAL_CFG, 0x000f0000);
+
+	/* setup PCI windows - window0 for MEM/config, window1 for IO */
+	ddb_set_pdar(PADR_PCIW0, 0x10000000, 0x08000000, 32, 0, 1);
+	ddb_set_pdar(PADR_PCIW1, 0x18000000, 0x00800000, 32, 0, 1);
+	ddb_set_pdar(PADR_IOPCIW0, 0x18800000, 0x00800000, 32, 0, 1);
+	ddb_set_pdar(PADR_IOPCIW1, 0x19000000, 0x00800000, 32, 0, 1);
+	/* ------------ reset PCI bus and BARs ----------------- */
+	ddb_pci_reset_bus();
+	/* Ext. PCI memory space */
+	ddb_out32(PCI_BAR_MEM01, 0x00000008);
+	ddb_out8(PCI_MLTIM, 0x40);
+
+	ddb_out32(PCI_BAR_LCS0, 0xffffffff);
+	ddb_out32(PCI_BAR_LCS1, 0xffffffff);
+	ddb_out32(PCI_BAR_LCS2, 0xffffffff);
+	ddb_out32(PCI_BAR_LCS3, 0xffffffff);
+	/* Int. PCI memory space */
+	ddb_out8(IPCI_MLTIM, 0x40);
+
+	ddb_out32(IPCI_BAR_LCS0, 0xffffffff);
+	ddb_out32(IPCI_BAR_LCS1, 0xffffffff);
+	ddb_out32(IPCI_BAR_LCS2, 0xffffffff);
+	ddb_out32(IPCI_BAR_LCS3, 0xffffffff);
+	ddb_out32(IPCI_BAR_IREG, 0xffffffff);
+
+	/*
+	 * We use pci master register 0  for memory space / config space
+	 * And we use register 1 for IO space.
+	 * Note that for memory space, we bump up the pci base address
+	 * so that we have 1:1 mapping between PCI memory and cpu physical.
+	 * For PCI IO space, it starts from 0 in PCI IO space but with
+	 * IO_BASE in CPU physical address space.
+	 */
+	ddb_set_pmr(EPCI_INIT0, DDB_PCICMD_MEM, 0x10000000, DDB_PCI_ACCESS_32);
+	ddb_set_pmr(EPCI_INIT1, DDB_PCICMD_IO, 0x00001000, DDB_PCI_ACCESS_32);
+	ddb_set_pmr(IPCI_INIT0, DDB_PCICMD_MEM, 0x18800000, DDB_PCI_ACCESS_32);
+	ddb_set_pmr(IPCI_INIT1, DDB_PCICMD_IO, 0x01000000, DDB_PCI_ACCESS_32);
+
+	/* PCI cross window should be set properly */
+	ddb_set_pdar(PCI_BAR_IPCIW0, 0x18800000, 0x00800000, 32, 0, 1);
+	ddb_set_pdar(PCI_BAR_IPCIW1, 0x19000000, 0x00800000, 32, 0, 1);
+	ddb_set_pdar(IPCI_BAR_EPCIW0, 0x10000000, 0x08000000, 32, 0, 1);
+	ddb_set_pdar(IPCI_BAR_EPCIW1, 0x18000000, 0x00800000, 32, 0, 1);
+
+	/* setup GPIO */
+	ddb_out32(GIU_DIR0, 0xf7ebffdf);
+	ddb_out32(GIU_DIR1, 0x000007fa);
+	ddb_out32(GIU_FUNCSEL0, 0xf1c1ffff);
+	ddb_out32(GIU_FUNCSEL1, 0x000007f0);
+	chk_init_5701_reg(GIU_DIR0, 0xf7ebffdf);
+	chk_init_5701_reg(GIU_DIR1, 0x000007fa);
+	chk_init_5701_reg(GIU_FUNCSEL0, 0xf1c1ffff);
+	chk_init_5701_reg(GIU_FUNCSEL1, 0x000007f0);
+
+	/* enable USB input buffers */
+	ddb_out32(PIB_MISC, (ddb_in32(PIB_MISC) | 0x00000031));
+}
+
+static int __init shima_tcube_setup(void)
+{
+	set_io_port_base(0xB8000000);
+
+	board_time_init = tcube_time_init;
+	board_timer_setup = tcube_timer_setup;
+
+	_machine_restart = tcube_machine_restart;
+	_machine_halt = tcube_machine_halt;
+	_machine_power_off = tcube_machine_power_off;
+
+	/* setup resource limits */
+	ioport_resource.end = 0x02000000;
+	iomem_resource.end = 0xffffffff;
+
+	/* Reboot on panic */
+	panic_timeout = 30;
+
+#ifdef CONFIG_FB
+	conswitchp = &dummy_con;
+#endif
+
+	tcube_board_init();
+
+#if defined(CONFIG_BLK_DEV_INITRD)
+	ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
+	initrd_start = (unsigned long)&__rd_start;
+	initrd_end = (unsigned long)&__rd_end;
+#endif
+	register_pci_controller(&VR5701_ext_controller);
+	register_pci_controller(&VR5701_io_controller);
+	return 0;
+}
+
+void __init bus_error_init(void)
+{
+	/* do nothing */
+}
+
+early_initcall(shima_tcube_setup);
diff -Naurp --exclude=CVS linux_save/include/asm-mips/bootinfo.h linux_mips/include/asm-mips/bootinfo.h
--- linux_save/include/asm-mips/bootinfo.h	2005-03-01 09:33:17.000000000 +0300
+++ linux_mips/include/asm-mips/bootinfo.h	2005-05-31 19:03:48.000000000 +0400
@@ -215,6 +215,12 @@
 #define MACH_GROUP_TITAN       22	/* PMC-Sierra Titan		*/
 #define  MACH_TITAN_YOSEMITE	1	/* PMC-Sierra Yosemite		*/
 
+/*
+ * Valid machtype for group SHIMA
+ */
+#define MACH_GROUP_SHIMA       24 /* SHIMAFUJI                              */
+#define MACH_SHIMA_TCUBE         0      /* SHIMAFUJI T-Cube(Vr5701) */
+
 #define CL_SIZE			COMMAND_LINE_SIZE
 
 const char *get_system_type(void);
diff -Naurp --exclude=CVS linux_save/include/asm-mips/serial.h linux_mips/include/asm-mips/serial.h
--- linux_save/include/asm-mips/serial.h	2005-03-04 20:24:33.000000000 +0300
+++ linux_mips/include/asm-mips/serial.h	2005-05-31 19:10:01.000000000 +0400
@@ -391,6 +391,21 @@
 #define DDB5477_SERIAL_PORT_DEFNS
 #endif
 
+#ifdef CONFIG_TCUBE
+#include <asm/tcube.h>
+#define TCUBE_SERIAL_PORT_DEFNS                                   \
+	{ baud_base: BASE_BAUD, irq: 16, flags: STD_COM_FLAGS,          \
+	  iomem_base: (u8*)0xbe000a00, iomem_reg_shift: 3,              \
+	  io_type: SERIAL_IO_MEM},\
+	{ baud_base: BASE_BAUD, irq: 17, flags: STD_COM_FLAGS,          \
+	  iomem_base: (u8*)0xbe000a40, iomem_reg_shift: 3,              \
+	  io_type: SERIAL_IO_MEM},
+#else
+#define TCUBE_SERIAL_PORT_DEFNS
+#endif
+
+
+
 #ifdef CONFIG_SGI_IP32
 /*
  * The IP32 (SGI O2) has standard serial ports (UART 16550A) mapped in memory
@@ -416,6 +431,7 @@
 	MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS		\
 	MOMENCO_OCELOT_SERIAL_PORT_DEFNS		\
 	MOMENCO_OCELOT_3_SERIAL_PORT_DEFNS		\
-	AU1000_SERIAL_PORT_DEFNS
+	AU1000_SERIAL_PORT_DEFNS			\
+	TCUBE_SERIAL_PORT_DEFNS
 
 #endif /* _ASM_SERIAL_H */
diff -Naurp --exclude=CVS linux_save/include/asm-mips/tcube.h linux_mips/include/asm-mips/tcube.h
--- linux_save/include/asm-mips/tcube.h	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/include/asm-mips/tcube.h	2005-05-31 19:03:48.000000000 +0400
@@ -0,0 +1,201 @@
+/*
+ * include/asm-mips/tcube.h
+ *
+ * Flash memory access on NEC VR5701-SG2 board.
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef __TCUBE_H
+#define __TCUBE_H
+
+#include <asm/vr5701.h>
+
+#define TCUBE_SDRAM_SIZE 	0x10000000
+
+#ifndef __ASSEMBLY__
+#include <asm/delay.h>
+
+/*
+ *  PCI Master Registers
+ */
+
+#define DDB_PCICMD_IACK		0	/* PCI Interrupt Acknowledge */
+#define DDB_PCICMD_IO		1	/* PCI I/O Space */
+#define DDB_PCICMD_MEM		3	/* PCI Memory Space */
+#define DDB_PCICMD_CFG		5	/* PCI Configuration Space */
+
+/*
+ * additional options for pci init reg (no shifting needed)
+ */
+#define DDB_PCI_CFGTYPE1     	0x200	/* for pci init0/1 regs */
+#define DDB_PCI_ACCESS_32    	0x10	/* for pci init0/1 regs */
+#define NUM_5701_IRQS 	  	32
+#define NUM_5701_EPCI_IRQ 	4
+
+/* A Real Time Clock interface for Linux on NEC VR5701-SG2 */
+#define SET_32_BIT		0xffffffff
+#define CLR_32_BIT		0x00000000
+
+#define GPIO_3_INTR		(0x1 <<  3)
+#define GPIO_4_CE		(0x1 <<  4)
+#define GPIO_25_S1CLK		(0x1 << 25)
+#define GPIO_26_S1DO		(0x1 << 26)
+#define GPIO_27_S1DI		(0x1 << 27)
+#define GPIO_CSI1_PIN	(GPIO_25_S1CLK | GPIO_26_S1DO | GPIO_27_S1DI)
+
+#define CSIn_MODE_CKP		(0x1 << 12)
+#define CSIn_MODE_DAP		(0x1 << 11)
+#define CSIn_MODE_CKS_MASK	(0x7 <<  8)
+#define CSIn_MODE_CKS_833333MHZ	(0x1 <<  8)
+#define CSIn_MODE_CKS_416667MHZ	(0x2 <<  8)
+#define CSIn_MODE_CKS_208333MHZ	(0x3 <<  8)
+#define CSIn_MODE_CKS_104167MHZ	(0x4 <<  8)
+#define CSIn_MODE_CKS_052083MHZ	(0x5 <<  8)
+#define CSIn_MODE_CKS_0260417HZ	(0x6 <<  8)	/* Default */
+#define CSIn_MODE_CSIE		(0x1 <<  7)
+#define CSIn_MODE_TRMD		(0x1 <<  6)
+#define CSIn_MODE_CCL_16	(0x1 <<  5)
+#define CSIn_MODE_DIR_LSB	(0x1 <<  4)
+#define CSIn_MODE_AUTO		(0x1 <<  2)
+#define CSIn_MODE_CSOT		(0x1 <<  0)
+
+#define CSIn_INT_CSIEND		(0x1 << 15)
+#define CSIn_INT_T_EMP		(0x1 <<  8)
+#define CSIn_INT_R_OVER		(0x1 <<  0)
+
+/* IRQs */
+#define ACTIVE_LOW		1
+#define ACTIVE_HIGH		0
+
+#define LEVEL_SENSE		2
+#define EDGE_TRIGGER		0
+
+#define NUM_5701_IRQS 		32
+#define NUM_5701_EPCI_IRQS 	4
+#define NUM_5701_IPCI_IRQS 	8
+#define NUM_5701_IRQ  		32
+#define NUM_EPCI_IRQ  		4
+#define NUM_IPCI_IRQ  		8
+
+#define INTA			0
+#define INTB			1
+#define INTC			2
+#define INTD			3
+#define INTE			4
+
+/* Timers */
+#define	CPU_COUNTER_FREQUENCY		133333333
+
+#define ddb_sync       		io_sync
+#define ddb_out32(x,y) 		io_out32(x,y)
+#define ddb_out16(x,y) 		io_out16(x,y)
+#define ddb_out8(x,y)  		io_out8(x,y)
+#define ddb_in32(x)    		io_in32(x)
+#define ddb_in16(x)    		io_in16(x)
+#define ddb_in8(x)     		io_in8(x)
+
+static inline void io_sync(void)
+{
+	asm("sync");
+}
+
+static inline void io_out32(u32 offset, u32 val)
+{
+	*(volatile u32 *)(VR5701_IO_BASE + offset) = val;
+	io_sync();
+}
+
+static inline u32 io_in32(u32 offset)
+{
+	u32 val = *(volatile u32 *)(VR5701_IO_BASE + offset);
+	io_sync();
+	return val;
+}
+
+static inline void io_out16(u32 offset, u16 val)
+{
+	*(volatile u16 *)(VR5701_IO_BASE + offset) = val;
+	io_sync();
+}
+
+static inline u16 io_in16(u32 offset)
+{
+	u16 val = *(volatile u16 *)(VR5701_IO_BASE + offset);
+	io_sync();
+	return val;
+}
+
+static inline void io_reset16(unsigned long adr,
+			      unsigned short val1,
+			      unsigned delay, unsigned short val2)
+{
+	io_out16(adr, val1);
+	__delay(delay);
+	io_out16(adr, val2);
+}
+
+static inline void io_out8(u32 offset, u8 val)
+{
+	*(volatile u8 *)(VR5701_IO_BASE + offset) = val;
+	io_sync();
+}
+
+static inline u8 io_in8(u32 offset)
+{
+	u8 val = *(volatile u8 *)(VR5701_IO_BASE + offset);
+	io_sync();
+	return val;
+}
+
+static inline void io_set16(u32 offset, u16 mask, u16 val)
+{
+	u16 val0 = io_in16(offset);
+	io_out16(offset, (val & mask) | (val0 & ~mask));
+}
+
+static inline void reg_set32(u32 offset, u32 mask, u32 val)
+{
+	u32 val0 = io_in32(offset);
+	io_out32(offset, (val & mask) | (val0 & ~mask));
+}
+
+static inline void csi1_reset(void)
+{
+	/* CSI1 reset */
+	reg_set32(CSI1_CNT, 0x00008000, SET_32_BIT);	/* set CSIRST bit */
+	__delay(100000);
+	reg_set32(CSI1_CNT, 0x00008000, CLR_32_BIT);	/* clear CSIRST bit */
+	/* set clock phase  */
+	while (io_in32(CSI1_MODE) & 1) ;
+	reg_set32(CSI1_MODE, CSIn_MODE_CSIE, CLR_32_BIT);
+	reg_set32(CSI1_MODE, CSIn_MODE_CKP, SET_32_BIT);
+	reg_set32(CSI1_MODE, CSIn_MODE_CKS_104167MHZ, SET_32_BIT);
+	reg_set32(CSI1_MODE, CSIn_MODE_CSIE, SET_32_BIT);
+	while (io_in32(CSI1_MODE) & CSIn_MODE_CSOT) ;
+}
+
+extern void ll_vr5701_irq_route(int vr5701_irq, int ip);
+extern void ll_vr5701_irq_enable(int vr5701_irq);
+extern void ddb_set_pdar(u32, u32, u32, int, int, int);
+extern void ddb_set_pmr(u32 pmr, u32 type, u32 addr, u32 options);
+extern void ddb_set_bar(u32 bar, u32 phys, int prefetchable);
+extern void ddb_pci_reset_bus(void);
+extern struct pci_ops VR5701_ext_pci_ops;
+extern struct pci_ops VR5701_io_pci_ops;
+extern struct pci_controller VR5701_ext_controller;
+extern struct pci_controller VR5701_io_controller;
+extern int shima_tcube_setup(void);
+extern void tcube_irq_init(u32 base);
+extern void mips_cpu_irq_init(u32 base);
+extern asmlinkage void tcube_handle_int(void);
+extern void vr5701_irq_init(u32 irq_base);
+extern int setup_irq(unsigned int irq, struct irqaction *irqaction);
+extern int panic_timeout;
+
+#endif
+#endif
diff -Naurp --exclude=CVS linux_save/include/asm-mips/vr5701.h linux_mips/include/asm-mips/vr5701.h
--- linux_save/include/asm-mips/vr5701.h	1970-01-01 03:00:00.000000000 +0300
+++ linux_mips/include/asm-mips/vr5701.h	2005-05-31 19:03:48.000000000 +0400
@@ -0,0 +1,96 @@
+/*
+ * include/asm-mips/vr5701.h
+ *
+ * A header for NEC VR5701 CPU
+ *
+ * Author: Sergey Podstavin <spodstavin@ru.mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef __VR5701_H
+#define __VR5701_H
+
+#define VR5701_IO_BASE	0xbe000000
+
+/* PADR registers */
+#define PADR_SDRAM01	0x40
+#define PADR_LOCALCS0	0x80
+#define PADR_PCIW0	0xC0
+#define PADR_PCIW1	0xC8
+#define PADR_EPCIW0	0xC0
+#define PADR_IOPCIW0	0xE0
+#define PADR_IOPCIW1	0xE8
+/* INT registers */
+#define INT0_STAT	0x100
+#define INT1_STAT	0x108
+#define INT2_STAT	0x110
+#define INT3_STAT	0x118
+#define INT4_STAT	0x120
+#define NMI_STAT	0x130
+#define INT_CLR		0x140
+#define INT_MASK	0x150
+#define INT_ROUTE0	0x160
+#define INT_ROUTE1	0x168
+#define INT_ROUTE2	0x170
+#define INT_ROUTE3	0x178
+/* LOCAL registers */
+#define LOCAL_CST0	0x400
+#define LOCAL_CFG	0x440
+/* EPCI registers */
+#define EPCI_CTRLH	0x604
+#define EPCI_INIT0	0x610
+#define EPCI_INIT1	0x618
+#define EPCI_ERR	0x628
+#define EPCI_INTS	0x630
+#define EPCI_INTM	0x638
+/* PCI registers */
+#define PCI_MLTIM	0x70D
+#define PCI_BAR_MEM01	0x710
+#define PCI_BAR_LCS0	0x740
+#define PCI_BAR_LCS1	0x748
+#define PCI_BAR_LCS2	0x750
+#define PCI_BAR_LCS3	0x758
+#define PCI_BAR_IPCIW0	0x7A0
+#define PCI_BAR_IPCIW1	0x7A8
+#define PCI_BAR_IREG	0x7C0
+
+/* PIB registers*/
+#define PIB_RESET	0x800
+#define PIB_MISC	0x830
+
+/* GPIO registers*/
+#define GIU_PIO0	0x940
+#define GIU_DIR0	0x950
+#define GIU_DIR1	0x958
+#define GIU_FUNCSEL0	0x960
+#define GIU_FUNCSEL1	0x968
+
+/* CSI1 registers*/
+#define CSI1_MODE	0xB80
+#define CSI1_SIRB	0xB88
+#define CSI1_SOTB	0xB90
+#define CSI1_SOTBF	0xBA0
+#define CSI1_CNT	0xBC0
+#define CSI1_INT	0xBC8
+
+/* IPCI registers*/
+#define IPCI_CTRLH	0xE04
+#define IPCI_INIT0	0xE10
+#define IPCI_INIT1	0xE18
+#define IPCI_ERR	0xE28
+#define IPCI_INTS	0xE30
+#define IPCI_INTM	0xE38
+/* PCI registers */
+#define IPCI_MLTIM	0xF0D
+#define IPCI_BAR_LCS0	0xF40
+#define IPCI_BAR_LCS1	0xF48
+#define IPCI_BAR_LCS2	0xF50
+#define IPCI_BAR_LCS3	0xF58
+#define IPCI_BAR_EPCIW0	0xF80
+#define IPCI_BAR_EPCIW1	0xF88
+#define IPCI_BAR_IREG	0xFC0
+
+#endif				/*  __VR5701_H */

--=-mspiNCIP3YakTU/JruAA--


From maxim.osipov@gmail.com Tue May 31 17:30:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 31 May 2005 17:30:57 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.195]:23606 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8225837AbVEaQan> convert rfc822-to-8bit;
	Tue, 31 May 2005 17:30:43 +0100
Received: by zproxy.gmail.com with SMTP id 13so3025799nzp
        for <linux-mips@linux-mips.org>; Tue, 31 May 2005 09:30:36 -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=tc//QyzF5EgCmdS0798yp8Jbo8/IDArlgdvg0FvuH1yGZK7m09W/rQrtmq0Fju1UOBk8q/QkV1HdhQxnuiJoOyhT4k0N8HbDX4J/RocFVko7ndCj9dMT+Ya2HwnyAFqVFClcmv1eeqs8I4kArGKiYlXZtbOuF5TO0TXvHnGH6lU=
Received: by 10.36.2.16 with SMTP id 16mr2386171nzb;
        Tue, 31 May 2005 09:30:35 -0700 (PDT)
Received: by 10.36.68.6 with HTTP; Tue, 31 May 2005 09:30:35 -0700 (PDT)
Message-ID: <6097c4905053109307edb80a6@mail.gmail.com>
Date:	Tue, 31 May 2005 20:30:35 +0400
From:	Maxim Osipov <maxim.osipov@gmail.com>
Reply-To: maxim@mox.ru
To:	macro@linux-mips.org
Subject: Re: glibc-2.3.4 mips64 compilation failure
Cc:	linux-mips@linux-mips.org, dan@debian.org
In-Reply-To: <429C8F71.6080606@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <429C8F71.6080606@siemens.com>
Return-Path: <maxim.osipov@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8035
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maxim.osipov@gmail.com
Precedence: bulk
X-list: linux-mips

Yes, thanks - I'm already using it, for glibc it did help with my
problem. Binutils 2.16 and gcc 3.4.3 seems to compile out of box (wo
any patches), but I didn't try produced code on a hardware yet.

Best regards,
Maxim

On 5/31/05, Maxim Osipov <maxim.osipov@siemens.com> wrote:
> > Do anyone have a clue what is happening? AFAIK, some people already
> > had success building glibc for mips64. Probably I miss something?
> 
>   Please feel free to have a look at packages available at my site -- the
> setup may seem a little bit odd (n64 is used as the default format and
> actually the only one supported), but if you are after general setup,
> patches, etc. it is still relevant; just ignore the odd stuff.  Binary
> packages have been built with GCC 4.0.0, so probably the sources + patches
> are going to work with older tools as well.  You may consider using
> binutils 2.16, though (in general, not to solve your particular problem).
> 
>    Maciej
>