Re: [Qemu-devel] Anyone got qemu-system-ppc{,64} to boot anything?

[Rob Landley]

On Thursday 11 June 2009 05:07:18 Richard W.M. Jones wrote:
> The problem in the parent message was because I was using the wrong
> CPU.  Although the binary is called 'qemu-system-ppc64', don't be
> misled into thinking that means it'll emulate a 64 bit PowerPC
> processor!  Oh no, you have to supply the extra '-cpu ppc64'
> parameter.
>
> Most of the '-M' options appear to be non-functional, segfaulting or
> hanging or complaining about missing BIOS images.
>
> I've had no more luck with 'qemu-system-ppc'.
>
> So has _anyone_ got an example of qemu-system-ppc{,64} booting an OS
> that they can share with us?

I was using this:

http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-powerpc.tar.bz2

Extract the tarball, cd into the directory, and ./run-emulator.sh

That booted fine under svn 6657 (which is git 2d18e637e5ec), but every single
version since then has had something wrong with it.  (The following commit
screwed up openbios, which has since been fixed but other things broke.)

One of the problems is that since qemu started querying the hard drives from
openbios (git 513f789f6b18) the -hda option now sets /dev/hdc, and the cdrom
is /dev/hda.  (I.E. the primary and secondary controllers are swapped relative
to what the command line options claim to set.)

But that's easy enough to work around (just use -hdc on the command line and
/dev/hda in the kernel).  The second problem I haven't found a workaround for
yet, the kernel panics shortly after init takes control:

>Type exit when done.Unable to handle kernel paging request for data at
> address 0x0000007c Faulting instruction address: 0xc0125610
>Oops: Kernel access of bad area, sig: 11 [#1]
>PowerMac
>NIP: c0125610 LR: c013ea9c CTR: c013ea88
>REGS: c7827be0 TRAP: 0300   Not tainted  (2.6.29)
>MSR: 00009032 <EE,ME,IR,DR>  CR: 42224022  XER: 00000000
>DAR: 0000007c, DSISR: 40000000
>TASK = c78257f0[1] 'init.sh' THREAD: c7826000
>GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000 b9e82cb0
> 00000000 GPR08: c7821ed8 00000001 c013ea88 00000000 577d0280 100834dc
> 28220022 10060000 GPR16: 10080000 100852a8 00000000 10040000 00000000
> c0310000 c031594c c0270000 GPR24: 00000001 c0310000 0000000a c0310000
> c02ee370 00000000 00000001 00000000 NIP [c0125610] tty_wakeup+0x14/0xa0
>LR [c013ea9c] uart_tasklet_action+0x14/0x24
>Call Trace:
>[c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable)
>[c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24
>[c7827cb0] [c00303c8] tasklet_action+0x88/0x104
>[c7827cd0] [c00304d0] __do_softirq+0x8c/0x134
>[c7827d10] [c0006ba0] do_softirq+0x58/0x5c
>[c7827d20] [c003033c] irq_exit+0x94/0x98
>[c7827d30] [c0006c40] do_IRQ+0x9c/0xc0
>[c7827d50] [c0012778] ret_from_except+0x0/0x1c
>--- Exception: 501 at uart_start+0x24/0x38
>    LR = uart_start+0x20/0x38
>[c7827e30] [c014043c] uart_write+0xc4/0xe8
>[c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4
>[c7827eb0] [c0126540] tty_write+0x180/0x268
>[c7827ef0] [c007feec] vfs_write+0xc4/0x16c
>[c7827f10] [c0080404] sys_write+0x4c/0x90
>[c7827f40] [c00120ac] ret_from_syscall+0x0/0x40
>--- Exception: c01 at 0x4803a2dc
>    LR = 0x4804c490
>Instruction dump:
>38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020 9421fff0
>7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c 387f00d8
>Kernel panic - not syncing: Fatal exception in interrupt

This exact same binary image runs just fine under the earlier qemu version. 

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds