On 08/26/12 16:09, Alexander Graf wrote:
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.
Ok, nit, I have to insist, I'm on FreeBSD and I have not much clue how OpenBSD does it. We on FreeBSD have both, 32- and 64-bit PowerPC running. On the 64-bit side we even have a POWER7 emulation working inside qemu :)
So, do I get it right, either BAT _or_ HTAB? If so, I will study the HTAB code and find out what is happening, I need to read into to docs then.
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 :).
Hm, afaiu, we have three different 'of' modes, real-mode for cases where the firmware runs in real-mode. Meant for 32- and 64-bit real-mode. And two for virtual-mode one for 32- and one for 64-bit. As I remember I run into 32-bit virtual-mode. Might also be that the issue is here.
Another issue which came up in this thread, linux uses its own 'of' tree when the kernel is up while we still rely on the one form the firmware.
Will experiment a bit.
Thanks again for your patience!
Andreas