Subject: RapidIO - behavior after reboot

From: Thomas Moll <[email-masked]>
Date: Wed, 01 Jul 2009 11:36:22 +0200

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 <bio-0> 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
...