On 25.08.2012, at 03:05, Blue Swirl blauwirbel@gmail.com wrote:
On Sat, Aug 25, 2012 at 9:47 AM, Andreas TObler andreast@fgznet.ch wrote:
On 08/25/12 11:00, Blue Swirl wrote:
On Fri, Aug 24, 2012 at 9:45 PM, Andreas Tobler andreast@fgznet.ch wrote:
Hello,
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 issue.
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 PPC),
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.
Alex
since it's pointing to the low level entry point this could make sense.
At least on Sparc, the kernel should save the original MMU mappings and restore them on point of entry to OpenBIOS. Alternatively, you could try to arrange the code so that after you take control of MMU, OpenBIOS is not used anymore. For example, Linux builds an internal model of the Open Firmware tree and does not use the OF calls for OF tree lookup after the initial probe. I'd suppose NetBSD and OpenBSD kernel code could be used for reference since they work on PPC (real machines at least, I haven't tried on QEMU).
Thanks a lot! Andreas