On 25.08.2012, at 03:05, Blue Swirl <blauwirbel(a)gmail.com> wrote:
On Sat, Aug 25, 2012 at 9:47 AM, Andreas TObler
On 08/25/12 11:00, Blue Swirl wrote:
> On Fri, Aug 24, 2012 at 9:45 PM, Andreas Tobler
> <andreast(a)fgznet.ch> wrote:
>> I'm trying to get FreeBSD powerpc running with qemu. So far
>> it loads the fbsd loader and the loader loads the kernel. The
>> kernel starts booting but it hangs in an endless loop. It
>> tries to print out a fatal_trap but it looks like the 'of'
>> doesn't work properly (anymore?) at this stage.
>> I have a remote debugger attached to the kernel and I can see
>> where it hangs. But I can not figure out what caused the
>> fatal trap here.
>> An 'info registers' in qemu shows the srr0=fff025a4, this, as
>> I understand, points to of_client_callback from OpenBIOS.
>> (objdump -dS openbios-qemu.nostrip gives me this.)
>> qemu is on 1.1.90, iow, a git snapshot from yesterday with
>> OpenBIOS from 19th of aug.
>> Is there a possibilty to 'debug' the OpenBIOS somehow?
> CCing OpenBIOS list too.
> We have a built-in debugger in OpenBIOS (maybe not well
> documented). Then there's DEBUG_CIF in libopenbios/client.c and
> it should be possible to add debugging print statements to
> forth/system/ciface.fs too.
Oh, thank you. I'll take a look when I'm back on the machine.
>> I'm not sure whether it is a kernel issue or an OpenBIOS
> The problem could be that there's a MMU fault when the kernel
> calls OpenBIOS, maybe because OpenBIOS is no longer mapped (MMU
> disabled?) and then the above debugging would not help.
Hm, from the FreeBSD kernel code view, I passed several 'of'
calls to read the memory regions etc. to map memory. That said,
OB is working fine for the start. I'm not sure where it happens,
the fault above. It might be when I start to call 'of' again
after I have started the MMU on the FreeBSD kernel side.
So, to my understanding, you say it might be an MMU fault, that
OB is no longer mapped? Who would be the responsible for this
mapping, the FreeBSD kernel or OB?
Assuming that SRR0 is the fault address (I'm not so familiar with
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 in.
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.