[OpenBIOS] [Qemu-ppc] FreeBSD powerpc issue
Alexander Graf
agraf at suse.de
Sun Aug 26 06:24:12 CEST 2012
On 25.08.2012, at 10:01, Andreas Tobler wrote:
> On 25.08.12 16:36, Alexander Graf wrote:
>>
>>
>> On 25.08.2012, at 03:05, Blue Swirl <blauwirbel at gmail.com> wrote:
>>
>>> On Sat, Aug 25, 2012 at 9:47 AM, Andreas TObler
>>> <andreast at fgznet.ch> wrote:
>>>> On 08/25/12 11:00, Blue Swirl wrote:
>>>>>
>>>>> On Fri, Aug 24, 2012 at 9:45 PM, Andreas Tobler
>>>>> <andreast at 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.
>
> 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!
>
> Andreas
>
> From here I branch to 'of':
>
> NIP fff025a4 LR 0094e3f0 CTR fff025a4 XER 00000000
> MSR 00003030 HID0 00000000 HF 00002000 idx 1
> TB 00000000 554554156 DECR 3740413139
> GPR00 00000000009461c4 0000000000c7c090 0000000000c9c830 00000000d0004acc
> GPR04 00000000fff025a4 0000000000000000 0000000000001032 00000000d0004a80
> GPR08 000000000fd00000 0000000000c80000 0000000001c35f60 00000000d00049a0
> GPR12 000000000de9bba0 0000000000000000 00000000fff30714 00000000fff30ec8
> GPR16 00000000fff2f256 0000000004000000 00000000fffb36cc 00000000fffb3ecc
> GPR20 0000000000f68000 0000000000000004 00000000fff2f03f 00000000fff2efbf
> GPR24 00000000fff2f047 00000000fffb3630 0000000001c2f3b0 0000000001c325a8
> GPR28 0000000001c2ee6c 0000000001c35fbc 0000000000100100 00000000d00049a0
> CR 24000022 [ E G - - - - E E ] RES ffffffff
> FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPSCR 00000000
> SRR0 0092e658 SRR1 00083002 PVR 00080301 VRSAVE 00000000
> SPRG0 0fd00000 SPRG1 01c35f60 SPRG2 44000022 SPRG3 00000000
> SPRG4 00000000 SPRG5 00000000 SPRG6 00000000 SPRG7 00000000
> SDR1 0100001f
> get_bat: IBAT v fff025a4
> get_bat: IBAT0 v fff025a4 BATu 00001ffe BATl 00000012
> get_bat: IBAT1 v fff025a4 BATu 00000000 BATl 00000000
> get_bat: IBAT2 v fff025a4 BATu 00000000 BATl 00000000
> get_bat: IBAT3 v fff025a4 BATu 00000000 BATl 00000000
> no BAT match for fff025a4:
> get_bat: IBAT0 v fff025a4 BATu 00001ffe BATl 00000012
> 00000000 00000000 0ffe0000
> get_bat: IBAT1 v fff025a4 BATu 00000000 BATl 00000000
> 00000000 00000000 00000000
> get_bat: IBAT2 v fff025a4 BATu 00000000 BATl 00000000
> 00000000 00000000 00000000
> get_bat: IBAT3 v fff025a4 BATu 00000000 BATl 00000000
> 00000000 00000000 00000000
> Raise exception at fff025a4 => 00000003 (40000000)
This means that at address 0xfff025a4 we hit a
POWERPC_EXCP_ISI = 3, /* Instruction storage exception */
with flags
33
Set to 1 if MSR.IR=1 and the translation for an attempted access is not found in the Page Table; otherwise set to 0.
So something was trying to jump to code that is not mapped in the HTAB. The address is definitely an OpenBIOS address, so for some reason FreeBSD messed with the HTAB, didn't make sure that OpenBIOS is still mapped in and then jumped to it. I wonder why the code works on real hardware?
> NIP 00000400 LR 0094e3f0 CTR fff025a4 XER 00000000
> MSR 00001000 HID0 00000000 HF 00000000 idx 1
> TB 00000000 554556831 DECR 3740410465
> GPR00 00000000009461c4 0000000000c7c090 0000000000c9c830 00000000d0004acc
> GPR04 00000000fff025a4 0000000000000000 0000000000001032 00000000d0004a80
> GPR08 000000000fd00000 0000000000c80000 0000000001c35f60 00000000d00049a0
> GPR12 000000000de9bba0 0000000000000000 00000000fff30714 00000000fff30ec8
> GPR16 00000000fff2f256 0000000004000000 00000000fffb36cc 00000000fffb3ecc
> GPR20 0000000000f68000 0000000000000004 00000000fff2f03f 00000000fff2efbf
> GPR24 00000000fff2f047 00000000fffb3630 0000000001c2f3b0 0000000001c325a8
> GPR28 0000000001c2ee6c 0000000001c35fbc 0000000000100100 00000000d00049a0
> CR 24000022 [ E G - - - - E E ] RES ffffffff
> FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPSCR 00000000
> SRR0 fff025a4 SRR1 40003030 PVR 00080301 VRSAVE 00000000
> SPRG0 0fd00000 SPRG1 01c35f60 SPRG2 44000022 SPRG3 00000000
> SPRG4 00000000 SPRG5 00000000 SPRG6 00000000 SPRG7 00000000
> SDR1 0100001f
> IN:
> 0x00000400: mtsprg 1,r1
> 0x00000404: mflr r1
> 0x00000408: mtsprg 2,r1
> 0x0000040c: li r1,32
> 0x00000410: bla 0x10074c
This is the ISI interrupt handler :).
Alex
More information about the OpenBIOS
mailing list