qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] MorphOS 4.x on QEMU


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] MorphOS 4.x on QEMU
Date: Thu, 27 Feb 2014 22:27:48 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 26/02/14 21:41, BALATON Zoltan wrote:

On Wed, 26 Feb 2014, Alexander Graf wrote:
I'm fairly sure most people don't particularly have a good idea what's
going wrong for you :).

That's OK, I expect not many people are interested in this but I wasn't
sure that anyone actually reads these mails. My questions were not about
MorphOS but about QEMU, openbios and PPC Macs so maybe people knowing
these could help even if they don't know MorphOS.

zeroing the 0x80 address causes an exception problem.

That's probably a NULL pointer exception. Your bootloader is trying to
find something, doesn't find it, returns NULL, something else takes the
return value as granted and accesses that pointer + 0x80.

I don't think so. The code I've quoted in my first message is all that
runs up to this assignment from 0x400000 which is the base, start
address of the boot loader. Before that everything that runs is part of
openbios. Besides, as far as I can read ppc assembly I don't see where
it could try to get a return address in this code:

0x00400058: li r22,0
0x0040005c: li r9,128
0x00400060: mr r26,r5
0x00400064: mr r25,r6
0x00400068: stw r22,0(r9)

which looks like a direct assignment to 0x80 to me. What am I missing?
Could it be that on real hardware the boot loader is run with a
different PID so the memory is not overlapping the interrupt vectors or
on a Mac this address is not part of the interrupt vectors? First of all
why does the bootloder try to set this address to zero? It makes no
sense to me. Is there anything mapped there on a PPC Mac?

So far PCI passthrough has only been done on IBM POWER (-M pseries) and
Freescale e500 (-M ppce500) systems. I doubt MorphOS runs on either of
them.

AFAIK, it does not. Apart from some PPC Macs it supports a few boards
some of them with some Freescale parts but I need to check how similar
is that to what QEMU already has. I'm starting to think that targeting
these may be an easier route now because on the Mac it only supports
some specific Radeon cards while on other boards some more may work too.

Plus PCI passthrough is pretty hard to get right with TCG - so
this is something I don't think anyone attempted so far.

If you like to give it a go though, try to make something slightly more
simple work first though :). VGA adapters are hell.

I did not mean to share a video card with the host but to have a second
card dedicated to the guest of course. But it seems to be too big
undertaking for me if noone else has tried that before. (And I'd need to
dig up a compatible card first to try it.)

There's a web page somewhere with lots of device tree dumps from systems
all over the place. I don't have the link right now, but I'm sure Google
knows more :).

I've tried to find that but so far I only could find ioregs dumps from
Intel Macs. I'll keep trying to locate that page then.

Sadly the actual pages have been removed so the only recourse is use the wayback machine: http://web.archive.org/web/20081120133742/http://penguinppc.org/historical/dev-trees-html/

I've got local copies of these files just in case, but I should really think about getting them preserved on the OpenBIOS wiki somewhere...


ATB,

Mark.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]