[OpenBIOS] [Qemu-ppc] FreeBSD powerpc issue

Alexander Graf agraf at suse.de
Sun Aug 26 16:09:56 CEST 2012


On 25.08.2012, at 22:47, Andreas Tobler wrote:

> Hi Alex!
> 
> On 26.08.12 06:24, Alexander Graf wrote:
> 
>>> 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:
> 
> And about this one I do not have to worry?

book3s_32 (which the G3s and G4s are) have 2 ways of resolving an effective address (virtual in x86 speech) to a real address (physical address in x86 speech).

BAT

There are a number of BAT registers. They basically contain mappings that contain

  - effective offset of a region
  - length of the region
  - real offset of the region

thus allow you to map an address range

  EA & ~mask -> RA | (EA & mask)

So Linux for example uses them to map

  EA 0xc0000000 - 0xcfffffff -> RA 0x00000000 -- 0x0fffffff

HTAB

This is the "normal" way of dealing with the MMU on non-embedded PPC. You have a big hash table in memory that contains maps for all processes at the same time, with a tag on which one you are at a time. The map which process you are at happens through the segment registers (SR).

OpenBIOS uses an HTAB to map itself into your effective memory window. It also sets up its own SRs.

I would expect OpenBSD to set up its own maps in the HTAB and use different SRs. At that time, the OpenBIOS mappings are obviously gone.

> 
>>> 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?
> 
> Aha, this gives me a challenge to find out what is happening.
> It works on real hw, but from my observation it sometimes 'hangs' and to find out about this issue I started to play with qemu ;)
> 
> Thank you very much.
> 
> Now I have to find out about why the OpwnBIOS area is not mapped.
> Is it the case that the 'of' code on Apple HW is located elsewhere, not on such high address like 0xfff00000? Or should that not matter?

Phew. I honestly have no idea how this would work at all even on Apple HW. Linux simply handles everything from real mode (disable paging) when going into anything firmware related. I have no idea what OpenBSD does. If you could try to find out and summarize it, I might be able to reconstruct how it could work :).


Alex




More information about the OpenBIOS mailing list