Re: [Qemu-ppc] FreeBSD powerpc issue

[Alexander Graf]

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