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 <andreast(a)fgznet.ch> wrote:
>> 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:
>>>>
>>>> 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
>