[Qemu-devel] problems running QEMU as ARM RealView EB _Rev. C_

[ulfsen@binaervarianz.de]

Hello,
in the latest CVS snapshot the emulation for the ARM RealView
Emulation Baseboard is based on board revision B.
After changing the SCU base address from 0x10100000 (Board Rev.B) to
0x1F000000 (Board Rev.C) I was able to boot a non SMP linux
kernel(2.6.22).

--- ../../qemu-snapshot-2008-04-07_05/hw/mpcore.c       2008-04-07
12:59:11.000000000 +0200 +++ ../hw/mpcore.c      2008-04-01
17:58:58.000000000 +0200 @@ -11,7 +11,11 @@
   #include "qemu-timer.h"
   #include "primecell.h"

-#define MPCORE_PRIV_BASE  0x10100000
+/* Rev.C fix:
+ * SCU registers on Rev.B = 0x10100000
+ *              on Rev.C = 0x1F000000
+ */
+#define MPCORE_PRIV_BASE  0x1F000000
   #define NCPU 4
   /* ??? The MPCore TRM says the on-chip controller has 224 external IRQ
lines (+ 32 internal).  However my test chip only exposes/reports 32.

After that I tried a SMP kernel. The boot process on the Bootstrap
Processor is running fine but it fails initialising the Application
Processors.

...

Calibrating local timer... 95.58MHz.
CPU1: processor failed to boot
CPU2: processor failed to boot
CPU3: processor failed to boot
Brought up 1 CPUs
SMP: Total of 1 processors activated (399.76 BogoMIPS).

...


Now I am not sure if the softirq that is sent by the Bootstrap
Processor (done by the function calling smp_cross_call()
in arch/arm/mach-realview/platsmp.c) is received by the Application
Processors.

Now my main problem is that I coundn't find any information about
multicore debugging with the help of QEMU an GDB.
Even after changing the current CPU from 0 to 1 in QEMU console the QEMU
GDB stub is still running on CPU0.

Is there a way to do some debugging on CPU 1,2 or 3?
Or is there a way to monitor interupts in QEMU?
Or maybe I just missed to change an other base address while migrating
from Board Rev.B to rev.C?

Any ideas or comments are welcome!
---
Regards Ulf