| Message ID | ab2fb74d-b1ce-c488-782d-0ca8876470b5@kaod.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote: > But, I could not boot ./darwinppc-602.cdr with on a 970. That might > be another issue. Right, the issue is that the kernel in Darwin 6.0.2 doesn't support the 970 :-) I think the first MacOS X to support 970 was some special build of 10.2.8 or something along those lines, which is slightly after Darwin 6.0.2 was released. Now that being said, Darwin 8.0.1 is also not booting in 970 and that is possible a real issue, but I don't think it's realted to those patches since that happens with current upstream7 I can look into it later (they both boot fine with a 7400). Cheers, Ben.
On Mon, 2016-06-20 at 08:15 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote: > > But, I could not boot ./darwinppc-602.cdr with on a 970. That > > might > > be another issue. > > Right, the issue is that the kernel in Darwin 6.0.2 doesn't support > the > 970 :-) > > I think the first MacOS X to support 970 was some special build of > 10.2.8 or something along those lines, which is slightly after Darwin > 6.0.2 was released. > > Now that being said, Darwin 8.0.1 is also not booting in 970 and that > is possible a real issue, but I don't think it's realted to those > patches since that happens with current upstream7 > > I can look into it later (they both boot fine with a 7400). Ok so Darwin uses some of the HSPRG etc... that we don't emulate on the 970 so I suspect it never worked. I've added them but something else breaks, I'll dig, I have the kernel source so it shouldn't be too hard ;-) Cheers, Ben.
On Mon, 2016-06-20 at 08:35 +1000, Benjamin Herrenschmidt wrote: > , > Ok so Darwin uses some of the HSPRG etc... that we don't emulate on > the 970 so I suspect it never worked. I've added them but something > else breaks, I'll dig, I have the kernel source so it shouldn't be > too hard > ;-) Well, it ended up being harder than I thought. In fact I'm not there yet ! So the Darwin VM layer dies early because HID5 isn't set properly, thus dcbz is doing 128 bytes clear instead of 32, clobbering things. It looks like Apple's kernel doesn't set the right default in HID5, so we have to either do it in openbios or in qemu. Alex, what did you find out back in the day ? Or you never bothered running a 64-bit MacOS under PR KVM ? That fixed, it dies elsewhere in something related to page faults, still digging. Cheers, Ben.
On 20.06.16 09:08, Benjamin Herrenschmidt wrote: > On Mon, 2016-06-20 at 08:35 +1000, Benjamin Herrenschmidt wrote: >> , >> Ok so Darwin uses some of the HSPRG etc... that we don't emulate on >> the 970 so I suspect it never worked. I've added them but something >> else breaks, I'll dig, I have the kernel source so it shouldn't be >> too hard >> ;-) > > Well, it ended up being harder than I thought. In fact I'm not there > yet ! So the Darwin VM layer dies early because HID5 isn't set > properly, thus dcbz is doing 128 bytes clear instead of 32, clobbering > things. > > It looks like Apple's kernel doesn't set the right default in HID5, so > we have to either do it in openbios or in qemu. Alex, what did you find Uh, I'm fairy sure XNU sets HID5. > out back in the day ? Or you never bothered running a 64-bit MacOS > under PR KVM ? I don't think I ever had 64bit Mac OS X working in TCG or KVM :). Alex > That fixed, it dies elsewhere in something related to page faults, > still digging. > > Cheers, > Ben. >
On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote: > > That fixed, it dies elsewhere in something related to page faults, > still digging. > Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception ! qemu was leaving it to whatever value it had before. Kaboom. Now it crashes a bit further :-) Cheers, Ben.
On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote: > > > > That fixed, it dies elsewhere in something related to page faults, > > still digging. > > > Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception ! > > qemu was leaving it to whatever value it had before. Kaboom. > > Now it crashes a bit further :-) Right so it tries to load a MacRISC2 PE because we don't really emulate a MacRISC4 with U3 etc... and that isn't going to do it any good, really.. I'm not *actually* sure where MacOS gets itself into a spin, it seems to be poking at something at 0xf280_0000 which is somewhat odd as this would be the IO space and we have nothing there afaik, but I am not enough of a MacOS expert to figure out quite how to track down which kext it gets into etc... In any case, the machine we give it is definitely nowhere near a real G5 and that might be the main reason. More work needed. I'll still cleanup & submit my current crop of fixes in case somebody wants to have a look. Cheers, Ben.
On 06/20/2016 11:32 AM, Benjamin Herrenschmidt wrote: > On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote: >> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote: >>> >>> That fixed, it dies elsewhere in something related to page faults, >>> still digging. >>> >> Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception ! >> >> qemu was leaving it to whatever value it had before. Kaboom. >> >> Now it crashes a bit further :-) > Right so it tries to load a MacRISC2 PE because we don't really emulate > a MacRISC4 with U3 etc... and that isn't going to do it any good, > really.. > > I'm not *actually* sure where MacOS gets itself into a spin, it seems > to be poking at something at 0xf280_0000 which is somewhat odd as this > would be the IO space and we have nothing there afaik, but I am not > enough of a MacOS expert to figure out quite how to track down which > kext it gets into etc... > > In any case, the machine we give it is definitely nowhere near a real > G5 and that might be the main reason. More work needed. > > I'll still cleanup & submit my current crop of fixes in case somebody > wants to have a look. Since the patches do get you further along and get us closer to an actual 970, I guess it's a good idea to actually push them into the tree. Alex
On 20/06/16 10:32, Benjamin Herrenschmidt wrote: > On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote: >> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote: >>> >>> That fixed, it dies elsewhere in something related to page faults, >>> still digging. >>> >> Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception ! >> >> qemu was leaving it to whatever value it had before. Kaboom. >> >> Now it crashes a bit further :-) > > Right so it tries to load a MacRISC2 PE because we don't really emulate > a MacRISC4 with U3 etc... and that isn't going to do it any good, > really.. > > I'm not *actually* sure where MacOS gets itself into a spin, it seems > to be poking at something at 0xf280_0000 which is somewhat odd as this > would be the IO space and we have nothing there afaik, but I am not > enough of a MacOS expert to figure out quite how to track down which > kext it gets into etc... > > In any case, the machine we give it is definitely nowhere near a real > G5 and that might be the main reason. More work needed. A quick check with "info mtree" shows that this area of memory is PCI configuration space. There was a patch added to uninorth in order to suppress some PCI warnings on Darwin boot found by going over the source to the Darwin MacRISC driver which resulted in the patch at http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a74e6351e339523c16def. Maybe it could be related to that? > I'll still cleanup & submit my current crop of fixes in case somebody > wants to have a look. Not sure I can help much here, however I can give everything a good test and make sure that it doesn't break :) ATB, Mark.
On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote: > A quick check with "info mtree" shows that this area of memory is PCI > configuration space. There was a patch added to uninorth in order to > suppress some PCI warnings on Darwin boot found by going over the source > to the Darwin MacRISC driver which resulted in the patch at > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a74e6351e339523c16def. > Maybe it could be related to that? > > > I'll still cleanup & submit my current crop of fixes in case somebody > > wants to have a look. > > Not sure I can help much here, however I can give everything a good test > and make sure that it doesn't break :) I'll double check, I used to know that HW well and might even have access to some docs internally but that specific f280_0000 doesn't look like something that would mean anything on a machine with macio at 8000_0000.... Cheers, Ben.
On Tue, 2016-06-21 at 19:33 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote: > > A quick check with "info mtree" shows that this area of memory is > > PCI > > configuration space. There was a patch added to uninorth in order > > to > > suppress some PCI warnings on Darwin boot found by going over the > > source > > to the Darwin MacRISC driver which resulted in the patch at > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a > > 74e6351e339523c16def. > > Maybe it could be related to that? > > > > > I'll still cleanup & submit my current crop of fixes in case > > > somebody > > > wants to have a look. > > > > Not sure I can help much here, however I can give everything a good > > test > > and make sure that it doesn't break :) > > I'll double check, I used to know that HW well and might even have > access to some docs internally but that specific f280_0000 doesn't > look > like something that would mean anything on a machine with macio at > 8000_0000.... > You are right, it's PCI1 config space. I'll dig more later. Cheers, Ben.
Index: openbios.git/arch/ppc/qemu/start.S =================================================================== --- openbios.git.orig/arch/ppc/qemu/start.S +++ openbios.git/arch/ppc/qemu/start.S @@ -148,7 +148,20 @@ ll r31,(35 * ULONG_SIZE)(r1) ; \ .endif ; \ ll r1,(1 * ULONG_SIZE)(r1) ; /* restore stack at last */ \ - rfi + mtsprg1 r3 ; \ + mfpvr r3 ; \ + rlwinm r3,r3,16,16,31 ; \ + cmplwi cr1,r3,0x0039 ; /* 970 CPUs */ \ + beq- cr1,0f ; \ + cmplwi cr1,r3,0x003C ; /* 970fx CPUs */ \ + beq- cr1,0f ; \ + cmplwi cr1,r3,0x0044 ; /* 970mp CPUs */ \ + beq- cr1,0f ; \ + mfsprg1 r3 ; \ + rfi ; \ +0: ; \ + mfsprg1 r3 ; \ + rfid // PPC32