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
:).