On 25.08.12 19:37, Mark Cave-Ayland wrote:
On 25/08/12 18:01, Andreas Tobler wrote:
>> SRR0 is the fault IP. So if the fault at hand is an instruction
>> fetch fault, yes, that would be the address at fault. If it's a
>> data fault you would have to check DAR for the address it faults
>> It might also help to boot the guest with -d in_asm,cpu,int and
>> check out /tmp/qemu.log afterwards. Search for the IP that
>> faulted and see why exactly it did.
> Whoa!!! The first try I ended after the log grew over 5GB :)
> The next step was enabling the logging at a position where I knew
> it is going to happen soon.
> Below the excerpt from the qemu.log.
> Now the big question for me, what does this exactly say?
> Thanks for your hints, really appreciated!
Do you get any output with just OpenBIOS built with
in libopenbios/client.c? According to my email here, one of the
things I found a while back was that the dma-alloc method wasn't
defined in OpenBIOS for PPC when trying to boot (see the OpenBIOS
archives for more information).
Yeah, with this DEBUG option enabled I see something. The last entry is
about mmu and translations. Then it hangs. Well, it is in an endless
loop inside the FreeBSD kernel.
I my repeat myself, but the kernel starts booting from the loader.
And then, maybe after the mmu is on in the kernel? the exception occurs.
The dma-alloc issues I found in the archives appear much earlier in the
boot process, right? And do I get it right, that if needed, the
dma-alloc, I'd get an exception?
(Me new in this business ;)
> finddevice("/chosen") = 0xfff45644
> getprop(0xfff45644, "mmu", 0x00c21efc, 4) = 4
> 0x00c21efc 0f b5 a8 70 __ __ __ __ __ __ __ __ __ __ __ __ .??p
> instance-to-package(0x0fb5a870) = 0xfff521c8
> getproplen(0xfff521c8, "translations") = 0x00000250
> getprop(0xfff521c8, "translations", 0x00024000, 592) = 592
> 0x00024000 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00