Hollis Blanchard wrote:
On Fri, Jan 22, 2010 at 11:13 AM, Corey Minyard <minyard@xxxxxxx> wrote:
I tried using telnet for the console, and it worked for a little while:
root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb
oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
QEMU waiting for connection on: tcp:0.0.0.0:4444,server
Truncating memory to 64 MiB to fit SDRAM controller limits.
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) info kvm
kvm support: enabled
(qemu)
So things are getting closer, but there's no output on the telnet screen.
Doing an "info registers" causes qemu to abort.
I believe that's a known bug.
The following patch, which is almost certainly wrong, works around the
problem:
diff --git a/hw/ppc440.c b/hw/ppc440.c
index abe0a56..03ae356 100644
--- a/hw/ppc440.c
+++ b/hw/ppc440.c
@@ -44,6 +44,7 @@ CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus
**pcip,
qemu_irq *pic;
qemu_irq *irqs;
qemu_irq *pci_irqs;
+ uint32_t sysclk = 33333333;
if (cpu_model == NULL)
cpu_model = "405"; // XXX: should be 440EP
@@ -53,6 +54,9 @@ CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus
**pcip,
exit(1);
}
+ /* Set time-base frequency to sysclk */
+ ppc_emb_timers_init(env, sysclk);
+
ppc_dcr_init(env, NULL, NULL);
/* interrupt controller */
Now, nothing should have changed, but it's crashing at startup:
root@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI
mage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
QEMU waiting for connection on: tcp:0.0.0.0:4444,server
Truncating memory to 64 MiB to fit SDRAM controller limits.
I don't think it's related, but there must be a silly bug in
ppc4xx_sdram_adjust(). 128MB should require just a single bank in the
SDRAM controller.
QEMU 0.12.0 monitor - type 'help' for more information
(qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000
NIP 00000000 LR 00000000 CTR 00000000 XER 00000000
MSR 00000000 HID0 00000300 HF 00000000 idx 0
Segmentatio
backtrace show the invalid memory address, and the segfault is due to
something happening while printing out the information.
If you provide the backtrace, I can see if it looks familiar...
-Hollis
Here's how far I can get now:
root@xilinx-ml507:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 64
-M bambo
o -kernel uImage.bamboo -L . -append "" -serial tcp::4444,server
QEMU waiting for connection on: tcp:0.0.0.0:4444,server
Truncating memory to 64 MiB to fit SDRAM controller limits.
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) info cpus
* CPU #0: nip=0x00000000
(qemu) info registers
NIP 00000000 LR 00000000 CTR 00000000 XER 00000000
MSR 00000000 HID0 00000300 HF 00000000 idx 0
TB 00000000 00000bb4 DECR 00000000
GPR00 0000000000000000 0000000000fffff8 0000000000000000 0000000000000000
GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
CR 00000000 [ - - - - - - - - ] RES 00000000
FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR 00000000
SRR0 00000000 SRR1 00000000 SDR1 101d23e0
(qemu) x/10x 0
00000000: 0x00000000 0x00000000 0x00000000 0x00000000
00000010: 0x00000000 0x00000000 0x00000000 0x00000000
00000020: 0x00000000 0x00000000
(qemu)
So the ROM doesn't seem to be set up properly, though bamboo.dtb is in
the current directory.
I'm wondering if it is something bad about the memory setup.
-corey
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
