MOL and OSX on PPC604

[Dan A. Milisic]

People running Xpostfacto have this issue to address as well if they use =
a
604e.  The same 'fix' will allow MOL and native OSX to work on the 604e. =
=20

Just for laughs I installed MOL on an 8600 with a G3/250.  Installation =
went
fine.  Then I popped in the 604e processor and it died seconds after
startmol. =20

There's not a lot of info on this issue, but below is a post from
http://www.opendarwin.org/pipermail/hackers/2003-January/000387.html =
It's
written by the author of Xpostfacto (OSX on OldWorld hack) and had some =
good
tech info.

HTH,
D.

Darwin 6 and the 604e CPU
Ryan Rempel
Mon, 20 Jan 2003 16:09:47 -0600
ubject ] [ author ]

Darwin 6 (and Mac OS X 10.2) will not run on the 604e CPU. Previous=20
versions of Darwin (and Mac OS X) did (with a little help). I have been=20
trying to figure out what changed, and have recently made a certain=20
amount of progress. I thought I would write up my results and see if=20
anyone could suggest anything. For those of you who want the short=20
version, it looks like at least one of the problems lies in the sc=20
(System Call) handler in <xnu/osfmk/ppc/lowmem_vectors.s>. Read on for=20
details.

The symptom when you try to run Darwin 6 on a 604e CPU is that you get=20
as far as a white square in the upper-left corner of the display, and=20
then everything stops. It occurred to me to check whether kprintf had=20
been initialized. So I set things up to get kprintf output on a second=20
machine, and lo and behold, you do get some output from kprintf before=20
everything stops. So I compiled a custom kernel with some more kprintf=20
statements thrown in, and some debugging messages turned on, and here=20
is what I get. (You'll note that I'm compiling from the OpenDarwin tag=20
OD_APPLE_10_2. Anything later won't compile because of the missing=20
vfs_journal files that others have mentioned already):

kprintf initialized
version_variant =3D
version         =3D Darwin Kernel Version 6.0:
Mon Jan 20 12:27:08 CST 2003; ryan:BUILD/obj/RELEASE_PPC


About to call ppc_vm_init
Entering ppc_vm_init
sectTEXT: 11000, size: 292000
sectDATA: 2a3000, size: 8d000
sectLINK: 366000, size: 7aaf8
sectKLD:  330000, size: 36000
end: 3e1000
mem_size: 128 M
About to call pmap_bootstrap
Returning from pmap_bootstrap
Mapping memory:
    exception vector: 00002000, 00002000 - 00011000
           sectTEXTB: 00011000, 00011000 - 002A3000
           sectDATAB: 002A3000, 002A3000 - 00330000
           sectLINKB: 00366000, 00366000 - 003E1000
            sectKLDB: 00330000, 00330000 - 00366000
                 end: 003E1000, 003E1000 - 0105B000
About to call pmap_map 3 times
Returned from pmap_map once
Returned from pmap_map twice
Returned from pmap_map three times
About to make pmap entires for sectKLDB
Finished make pmap entires for sectKLDB
About to make pmap entires for sectLINKB
Finished make pmap entires for sectLINKB
About to make pmap entires for the remainder
Finished make pmap entires for the remainder
Free region start 0x0105b000 end 0x02000000
Free region start 0x0228a000 end 0x08000000
About to call LoadIBATs

Most of this is from <xnu/osfmk/ppc/ppc_vm_init.c> (and, of course, I=20
have added some kprintf's).

So it rather looks as though the call to LoadIBATs is not returning.=20
Now, LoadIBATs is defined in <xnu/osfmk/ppc/Firmware.s>, and it works=20
in a curious manner. The LoadIBATs routine itself issues an sc command=20
(i.e. system call), which generates an interrupt that will eventually=20
transfer control to xLoadIBATsLL, which is also defined in=20
<xnu/osfmk/ppc/Firmware.s>. I can't say that I understand why the=20
indirection is necessary--it probably has to do with translations and=20
the like--I'm afraid that I don't understand this stuff nearly as well=20
as I'd like to.

So, let's construct a theory about why this isn't working on the 604.=20
Let's start with the xLoadIBATsLL itself. All that it does is as=20
follows:

ENTRY(xLoadIBATsLL, TAG_NO_FRAME_USED)

			lwz		r4,0(r3)
/* Get IBAT 0 high */
			lwz		r5,4(r3)
/* Get IBAT 0 low */
			lwz		r6,8(r3)
/* Get IBAT 1 high */
			lwz		r7,12(r3)
/* Get IBAT 1 low */
			lwz		r8,16(r3)
/* Get IBAT 2 high */
			lwz		r9,20(r3)
/* Get IBAT 2 low */
			lwz		r10,24(r3)
/* Get IBAT 3 high */
			lwz		r11,28(r3)
/* Get IBAT 3 low */
		=09
			sync
/* Common decency and the state law require that you=20
wash your hands */
			mtibatu	0,r4
/* Load IBAT 0 high */
			mtibatl	0,r5
/* Load IBAT 0 low */
			mtibatu	1,r6
/* Load IBAT 1 high */
			mtibatl	1,r7
/* Load IBAT 1 low */
			mtibatu	2,r8
/* Load IBAT 2 high */
			mtibatl	2,r9
/* Load IBAT 2 low */
			mtibatu	3,r10
/* Load IBAT 3 high */
			mtibatl	3,r11
/* Load IBAT 3 low */
			sync
/* Make sure it's done */
			isync
/* Toss out anything new */
		=09
			blr
/* Leave... */

Now, this code didn't change between 10.1.5 and 10.2, so it can't be=20
the problem directly. So, what about the values being loaded? They are=20
filled in earlier in <xnu/osfmk/ppc/ppc_init.c>, and each given the=20
value of BAT_INVALID. This value did not change from 10.1.5 to 10.2, so=20
presumably it isn't the problem either.

The possibility which remains is the problem is not in the xLoadIBATsLL=20
function itself, but instead in the mechanism used to get there. Moving=20
backwards in the sequence, what calls xLoadIBATsLL is the FirmwareCall=20
function defined in <xnu/osfmk/ppc/Firmware.s>. However, FirmwareCall=20
did not change between 10.1.5 and 10.2, so it probably is not the=20
problem.

So, what calls FirmwareCall? That would be the exception_entry function=20
in <xnu/osfmk/ppc/lowmem_vectors.s>, which in turn is called by=20
L_handlerC00 (that is, the system call handler), also in=20
<xnu/osfmk/ppc/lowmem_vectors.s>.

If you look at exception_entry, you will notice that the way in which=20
FirmwareCall is called changed from 10.1.5 to 10.2. Here's the diff,=20
with 10.1.5 being the "-" part and 10.2 being the "+".

-			lis		r1,hi16(EXT(FirmwareCall))
/* Top half of firmware call=20
handler */
-			ori		r1,r1,lo16(EXT(FirmwareCall))	/*
Bottom half of it */
-			lwz		r3,saver3(r13)
/* Restore the first parameter, the rest=20
are ok already */
-			mtlr	r1
/* Get it in the link register */
-			blrl
/* Call the handler */
+			lwz		r3,saver3(r13)
; Restore the first parameter
+			bl		EXT(FirmwareCall)
; Go handle the firmware call....

So far as I can tell, the two versions are functionally identical. Just=20
in case, I tried compiling a kernel with the 10.1.5 version, and it did=20
not make a difference.

So then, we need to scan forwards and backwards, since it isn't clear=20
whether it fails before this point or after this point (but before the=20
rfi). I suppose I have this narrowed down far enough now that I could=20
just use the two-machine debugging to step through. Except that=20
translations and interrupts are off while you handle interrupts, so I=20
wonder whether debugging works? I suppose there is only one way to find=20
out ...

In any event, there are a lot of changes between 10.1.5 and 10.2 in the=20
sc (System Call) handling code (and interrupt handling in=20
lowmem_vectors.s generally). Presumably something in there is causing=20
the problem, but my brain is beginning to hurt, so I shall leave it for=20
the moment and come back to it later.

One thing that I did try is to call xLoadIBATsLL directly, rather than=20
going through the System Call process. Interestingly enough, that=20
produced the same result. So either the problem is not in the System=20
Call process after all, or (more likely) you really do need to go=20
through the system call process for it to work (i.e. it failed for a=20
different reason).

If anyone has any insight into any of this, I would be most grateful!=20
In particular, can anyone point me to the relevant differences between=20
the 604 and the G3? Is there an unsupported instruction that I should=20
be looking for, or what?

=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 6/30/2003
=20