From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 3C9ECB70F2 for ; Wed, 1 Jul 2009 20:12:49 +1000 (EST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "demumfd001.nsn-inter.net", Issuer "VeriSign Class 3 Secure Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 51684DDD0C for ; Wed, 1 Jul 2009 20:12:46 +1000 (EST) Message-ID: <4A4B2E16.9080200@nsn.com> Date: Wed, 01 Jul 2009 11:36:22 +0200 From: Thomas Moll MIME-Version: 1.0 To: ext Li Yang Subject: RapidIO - behavior after reboot Content-Type: text/plain; charset=windows-1252; format=flowed Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, we are using an EP8548 eval board from Embedded Planet and we have a problem with the RapidIO controller/Linux driver if we perform a reboot. On the second boot phase (after reboot), Linux will always print the following message when it loads the RapidIO driver: “RIO: doorbell queue full” We have debugged the RapidIO driver in Linux and we found out that the problem is located in the setup function of the doorbells. On the second boot phase after reboot, Linux will update dequeue/enqueue pointers to the first entry in the ring, but this is maybe not allowed when the doorbell controller is enabled (doorbell controller was already enabled by the first boot). We have checked all the registers of the RapidIO controller if they will contain the reset value after a reboot, but the registers contain the values that were used on the latest setting. We have checked the reset behavior of the RapidIO controller by sending the HRESET_REQ signal and with a reset generated by the Debug Control Register 0. Do you have any idea how to solve the problem and maybe solve future problems with enumeration? You can find the log of the second boot on the bottom. You can also find there the processor and core version of the used MPC8548 processor. --Thomas .... U-Boot 1.3.3 (Jul 17 2008 - 09:29:31) CPU: 8548_E, Version: 1.1, (0x80390011) Core: E500, Version: 1.0, (0x80210010) Clock Configuration: CPU:1000 MHz, CCB: 334 MHz, DDR: 167 MHz (334 MT/s data rate), LBC: 41 MHz L1: D-cache 32 kB enabled I-cache 32 kB enabled Board: EP8548 I2C: ready DRAM: Initializing Reusing current 256MB configuration DDR: 256 MB FLASH: 16 MB L2 cache 512KB: already enabled. In: serial Out: serial Err: serial Net: eTSEC0, eTSEC1, eTSEC2, eTSEC3 Hit any key to stop autoboot: 0 Speed: 1000, full duplex BOOTP broadcast 1 DHCP client bound to address 129.168.3.241 Using eTSEC0 device TFTP from server 129.168.1.85; our IP address is 129.168.3.241 Filename '/quicc01/pImage'. Load address: 0x1000000 Loading: ################################################################# ################################ done Bytes transferred = 1419118 (15a76e hex) ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-2.6.29.1 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1419054 Bytes = 1.4 MB Load Address: 00400000 Entry Point: 00400560 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x10000000> (256MB) ethernet0: local-mac-address <- 00:10:ec:00:b3:b0 CPU clock-frequency <- 0x3b9aa2f0 (1000MHz) CPU timebase-frequency <- 0x27bc6ca (42MHz) CPU bus-frequency <- 0x13de3650 (333MHz) zImage starting: loaded at 0x00400000 (sp: 0x0ef7eae0) Allocating 0x2fd488 bytes for kernel ... gunzipping (0x00000000 <- 0x0040d000:0x006ffd84)...done 0x2df950 bytes Linux/PowerPC load: root=/dev/nfs/ rw console=ttyS0,115200 ip=on Finalizing device tree... flat tree at 0x70c300 Using EP8548 machine description Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb Linux version 2.6.29.1 (thmoll@demmc3qc) (gcc version 3.4.3) #12 PREEMPT Wed Jul 1 09:20:23 CEST 2009 Found legacy serial port 0 for /soc8548@e0000000/serial@4500 mem=e0004500, taddr=e0004500, irq=0, clk=333330000, speed=0 console [udbg0] enabled setup_arch: bootmem ep8548_setup_arch() arch: exit Top of RAM: 0x10000000, Total RAM: 0x10000000 Memory hole size: 0MB Zone PFN ranges: DMA 0x00000000 -> 0x00010000 Normal 0x00010000 -> 0x00010000 HighMem 0x00010000 -> 0x00010000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00010000 On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c02d8d84, node_mem_map c0300000 DMA zone: 512 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65024 pages, LIFO batch:15 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/nfs/ rw console=ttyS0,115200 ip=on mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs mpic: ISU size: 80, shift: 7, mask: 7f mpic: Initializing for 80 sources PID hash table entries: 1024 (order: 10, 4096 bytes) time_init: decrementer frequency = 41.666250 MHz time_init: processor frequency = 999.990000 MHz clocksource: timebase mult[60003ef] shift[22] registered clockevent: decrementer mult[aaa] shift[16] cpu[0] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) High memory: 0k Memory: 256512k/262144k available (2796k kernel code, 5364k reserved, 124k data, 117k bss, 152k init) Calibrating delay loop... 83.20 BogoMIPS (lpj=166400) Mount-cache hash table entries: 512 net_namespace: 296 bytes NET: Registered protocol family 16 bio: create slab at 0 NET: Registered protocol family 2 Switched to high resolution mode on CPU 0 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 Setting up RapidIO peer-to-peer network /soc8548@e0000000/rapidio@c0000 fsl-of-rio e00c0000.rapidio: Of-device full name /soc8548@e0000000/rapidio@c0000 fsl-of-rio e00c0000.rapidio: Regs start 0xe00c0000 size 0x20000 fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size 0x0000000020000000. fsl-of-rio e00c0000.rapidio: bellirq: 50, txirq: 53, rxirq 54 fsl-of-rio e00c0000.rapidio: Overriding RIO_PORT setting to single lane 0 fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial fsl-of-rio e00c0000.rapidio: Hardware port width: 4 fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256 RIO: doorbell queue full RIO: doorbell queue full RIO: doorbell queue full RIO: doorbell queue full RIO: doorbell queue full ...