Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Well, hello there.

I've gotten close-ish to getting a Franken-Leopard to boot. But close isn't close enough.

First, I painstakingly went through the Snow Leopard 10.6.0 Install DVD I have and identified a bunch of PPC compatible binaries in various key places like /usr/bin, /usr/lib, PrivateFrameworks, and so on. I listed the ones that were not PPC compatible. Then I selected all, minus the ones not compatible, and copied them over to the Snow Leopard/PPC disc image - including mach_kernel.

See the attached TXT file with this hardly scientific list.

Second, I booted. The G5 started to boot and then froze. In addition to some weird issue with mach_kernel permissions, which I fixed, it got stuck on HFSInit. (See first image.) This rang a bell, because if you see in the TXT file, the hdid, hdik, etc binaries were not PPC compatible. I think the kernel needed a newer version.

So, I went into Leopard and copied over those same binaries to their correct places to the Snow Leopard/Frankenstein/PPC disc. And rebooted. Amazingly, in verbose mode, Snow Leopard booted and started loading up.

Third, crash. See my final image. The intriguing bit of news is - the kernel loaded. Darwin Kernel 10.0.0. Alright, alright.

But the CPU went into a panic, because it cannot find the driver for this platform. This is really common for hackintosh systems, and they of course worked around it by loading special kexts and other good stuff to get non-compliant hardware loading. I don't know if we have that option with PowerPC machines. If the kernel was built without drivers, I'm not sure if we can patch them in later.

Still, this is intriguing. Any thoughts?
 

Attachments

  • NotPPCCompatible.txt
    1.6 KB · Views: 170
  • 205E4640-A341-4D1B-A8B9-48989DD77D35_1_201_a.jpeg
    205E4640-A341-4D1B-A8B9-48989DD77D35_1_201_a.jpeg
    1 MB · Views: 309
  • E45CE447-D0AE-4EF4-82D4-CD04AC94025D_1_201_a.jpeg
    E45CE447-D0AE-4EF4-82D4-CD04AC94025D_1_201_a.jpeg
    587.6 KB · Views: 215
Well, hello there.

I've gotten close-ish to getting a Franken-Leopard to boot. But close isn't close enough.

First, I painstakingly went through the Snow Leopard 10.6.0 Install DVD I have and identified a bunch of PPC compatible binaries in various key places like /usr/bin, /usr/lib, PrivateFrameworks, and so on. I listed the ones that were not PPC compatible. Then I selected all, minus the ones not compatible, and copied them over to the Snow Leopard/PPC disc image - including mach_kernel.

See the attached TXT file with this hardly scientific list.

Second, I booted. The G5 started to boot and then froze. In addition to some weird issue with mach_kernel permissions, which I fixed, it got stuck on HFSInit. (See first image.) This rang a bell, because if you see in the TXT file, the hdid, hdik, etc binaries were not PPC compatible. I think the kernel needed a newer version.

So, I went into Leopard and copied over those same binaries to their correct places to the Snow Leopard/Frankenstein/PPC disc. And rebooted. Amazingly, in verbose mode, Snow Leopard booted and started loading up.

Third, crash. See my final image. The intriguing bit of news is - the kernel loaded. Darwin Kernel 10.0.0. Alright, alright.

But the CPU went into a panic, because it cannot find the driver for this platform. This is really common for hackintosh systems, and they of course worked around it by loading special kexts and other good stuff to get non-compliant hardware loading. I don't know if we have that option with PowerPC machines. If the kernel was built without drivers, I'm not sure if we can patch them in later.

Still, this is intriguing. Any thoughts?

Yes, that is possible to hack kernel to made a support for unsupported machines. Like this old one, i think.

Xnu hack to unsupported machines
 
As i do little research, Apple released sources of xnu kernel (10.6 release too), which is still have PowerPC components inside to run kernel on PowerPC hardware. More than that - those components is present even in Lion kernels. However, the kernel in release 10.6 was built only to target x64_86 / i386 devices (Platform Expert not recognised PowerPC Machine).


I looked in the direction of Open Darwin (Darwin OS) and found that even the latest kernel for today can be built for PowerPC. In addition to this, I looked at the kernel architecture and found that the QuickTime subsystem is also responsible for the graphics (QuartzCore, etc ...).
 
Well, hello there.

I've gotten close-ish to getting a Franken-Leopard to boot. But close isn't close enough.

First, I painstakingly went through the Snow Leopard 10.6.0 Install DVD I have and identified a bunch of PPC compatible binaries in various key places like /usr/bin, /usr/lib, PrivateFrameworks, and so on. I listed the ones that were not PPC compatible. Then I selected all, minus the ones not compatible, and copied them over to the Snow Leopard/PPC disc image - including mach_kernel.

See the attached TXT file with this hardly scientific list.

Second, I booted. The G5 started to boot and then froze. In addition to some weird issue with mach_kernel permissions, which I fixed, it got stuck on HFSInit. (See first image.) This rang a bell, because if you see in the TXT file, the hdid, hdik, etc binaries were not PPC compatible. I think the kernel needed a newer version.

So, I went into Leopard and copied over those same binaries to their correct places to the Snow Leopard/Frankenstein/PPC disc. And rebooted. Amazingly, in verbose mode, Snow Leopard booted and started loading up.

Third, crash. See my final image. The intriguing bit of news is - the kernel loaded. Darwin Kernel 10.0.0. Alright, alright.

But the CPU went into a panic, because it cannot find the driver for this platform. This is really common for hackintosh systems, and they of course worked around it by loading special kexts and other good stuff to get non-compliant hardware loading. I don't know if we have that option with PowerPC machines. If the kernel was built without drivers, I'm not sure if we can patch them in later.

Still, this is intriguing. Any thoughts?
Good work!
Some thoughts:
*The OF screenshot with the file-owner errors indicates that after copying stuff over "to the right locations" you might not have set the correct ownership to the files. Best to do so in this case would be to use a tool like BatChmod and set permissions to root-wheel. Advantage over terminal-fiddling with the permissions is that it can be done recursively to whole (sub-)folders. And you can easily check the correct settings by picking unmodified files (kexts, frameworks, whatever) first.
*The first stage loader errors claiming not to match load addresses with kexts also already occur with 10A222 (or A380, see table on #1), so as others already speculated, the mechanism of how BootX pre-loads extensions might not be suitable any more for later-than-A190 builds. Might be fixed or circumvented somehow. The observation is, it happens already in the beta build zoo and not only in first final 10.6.0 release of SL.
 
Good points to consider.
Whats so disturbing is that also (slightly) newer frameworks have the same effect on A190.
I´ll try to replace the dylib you mentioned, without any other changes and see what happens.

You´re running A96 with the A190 kernel d2? Good to know if that´s the case. Even newer kernels could run then...?

As for the movie files: You could easily convert any movie you have (i.e. fullHD) into your desired format/container/codec/resolution with ffmpeg (on an intel mac, that is).
Or ask @0403979, he did some experiments on his iMac PPC recently with movie clips.
I didn't find out what codecs caused issues but the Matroska container seems to be the most unreliable. This is most likely due to the wider number of supported codecs when compared to other containers. I have no concrete data, unfortunately.
 
Yes, that is possible to hack kernel to made a support for unsupported machines. Like this old one, i think.

Xnu hack to unsupported machines

That was a fun read, even if I skimmed it quickly this morning.

I did a little more tinkering. Many of the key Leopard (10.5.8) files in Frameworks and .kexts are actually older than the development build. That makes sense. Apple probably doesn't want to go around changing Frameworks as much as possible in the middle of an OS cycle.

My dream would be that we just need to toss the right PPC kext in there for Snow Leopard to see on boot and everything is happy forever.

BUT - IOPlatformExpert.cpp is part of the kernel. It identifies my Mac correctly but doesn't know what to do from there on out. I'm just poking around this now: https://github.com/apple/darwin-xnu

FYI - this is the part that is called when it can't find what to do with my beautiful G5:

Code:
/*********************************************************************
* IOPanicPlatform class
*
* If no legitimate IOPlatformDevice matches, this one does and panics
* the kernel with a suitable message.
*********************************************************************/

class IOPanicPlatform : IOPlatformExpert {
    OSDeclareDefaultStructors(IOPanicPlatform);

public:
    bool start(IOService * provider);
};


OSDefineMetaClassAndStructors(IOPanicPlatform, IOPlatformExpert);


bool IOPanicPlatform::start(IOService * provider) {
    const char * platform_name = "(unknown platform name)";

    if (provider) platform_name = provider->getName();

    panic("Unable to find driver for this platform: \"%s\".\n",
        platform_name);

    return false;
}
 
Last edited:
Hi @0403979,

Do you have any files with a resolution of around 1000px width with
dvx codec that I can try?

@NathanJHill in the 096 server we have the kexts below inside IOPlatformPluginsFamily.kexy
maybe that's what is missing in the final version?

PowerMac7_2_PlatformPlugin.kext
PowerMac8_1_ThermalProfile.kext
PBG4_PlatformPlugin.kext
PBG4_ThermalProfile.kext
PowerMac9_1_ThermalProfile.kext
PowerMac11_2_PlatformPlugin.kext
PowerMac11_2_ThermalProfile.kext
PowerMac12_1_PlatformPlugin.kext
Simple_PlatformPlugin.kext
PowerMac12_1_ThermalProfile.kext

Best regards,
voidRunner
 
@NathanJHill in the 096 server we have the kexts below inside IOPlatformPluginsFamily.kexy
maybe that's what is missing in the final version?

PowerMac7_2_PlatformPlugin.kext
PowerMac8_1_ThermalProfile.kext
PBG4_PlatformPlugin.kext
PBG4_ThermalProfile.kext
PowerMac9_1_ThermalProfile.kext
PowerMac11_2_PlatformPlugin.kext
PowerMac11_2_ThermalProfile.kext
PowerMac12_1_PlatformPlugin.kext
Simple_PlatformPlugin.kext
PowerMac12_1_ThermalProfile.kext

Those are in the 10A190 build as well, and they are present in what I am trying to boot. Either the kernel isn't seeing those resources or the checks are actually compiled in. It's interesting because almost all documentation about the kernel that I have found indicated that the system is designed to look elsewhere for drivers and other info about the system, rather than always needing to recompile the kernel. So, still just exploring...
 
  • Like
Reactions: Larsvonhier
But there's something curious there
PowerMac12_1 ???

Best regards,
voidRunner
 
But there's something curious there
PowerMac12_1 ???

Best regards,
voidRunner

Yes, and 10A190 has a RackMac3,1 listed as well.

I've given up for now. Kept tinkering, switching around stuff, even moved over some Leopard kexts in key spots but it crashes at the same point.
 
I lost track, I confess: You´ve been trying to boot 10.6.0 release?

I know. The thread moves fast.

Yes, 10.6.0. At this point, I'm convinced either a) we need a new kernel that has ppc machines re-included in IOKit, which is possible if someone wants to build it targeted for PPC (I guess) or b) figure out where to point the kernel to find the right drivers to get it to finish loading. Right before it panics, you can see that it can't translate physical address for drivers. That's why I don't think it's merely not finding drivers - it's just not able to.

Moving from PPC to Intel was a big jump. While I don't think Apple would have made it so just a few rightly placed kexts/Frameworks make Snow Leopard PPC compatible, I also know that later versions of the OS have left off various machines and there have been workarounds to get older graphic cards working, for instance, by doing just that. So, I'll keep tinkering a bit more, but I do feel we will keep running up against a wall.
 
Hi guys,

Just a thought can't we use one of the DP's kernel and kexts?

I've done this on my CoreDUO Mackbook PRO to get it running Lion 10.7.5
while using the Kernel provided by dosdude and the kexts from 10.7.2.

Best regards,
voidRunner
 
I know. The thread moves fast.

Yes, 10.6.0. At this point, I'm convinced either a) we need a new kernel that has ppc machines re-included in IOKit, which is possible if someone wants to build it targeted for PPC (I guess) or b) figure out where to point the kernel to find the right drivers to get it to finish loading. Right before it panics, you can see that it can't translate physical address for drivers. That's why I don't think it's merely not finding drivers - it's just not able to.

Moving from PPC to Intel was a big jump. While I don't think Apple would have made it so just a few rightly placed kexts/Frameworks make Snow Leopard PPC compatible, I also know that later versions of the OS have left off various machines and there have been workarounds to get older graphic cards working, for instance, by doing just that. So, I'll keep tinkering a bit more, but I do feel we will keep running up against a wall.
Ok, thanks. I thought so but wanted to be sure. As said, this effect of not pre-loading the kexts starts from a certain dev build on, not just from 10.6.0 (which means, if solved, we could get a 10.6.0 final release running). Not sure if it´s solely Kernel-related, perhaps our BootX needs a re-compile of some sort, too. Your Ryan-Rempel doc offers really a good insight there...
As for the wall(s): I´ve been involved in the Catalina on C2D with OpenGL drama, and for a couple of weeks that wall seemed un-invincible also. Fun fact: As a German, I do not believe in walls too much ;-)

My gut feeling tells me that the road might split at some point: Pimping the A96 with older components (from 10.5.8) and finding/compiling newer ingredients for A190/A222 upwards.

Let´s see what we find out.
 
Hi guys,

Just a thought can't we use one of the DP's kernel and kexts?

I've done this on my CoreDUO Mackbook PRO to get it running Lion 10.7.5
while using the Kernel provided by dosdude and the kexts from 10.7.2.

Best regards,
voidRunner

Yes, this is what I am planning to try next - see if the development kernel, back in its right place, boots with the new Frameworks/kexts that I have moved over.

The only kexts I did end up moving over from Leopard had "created" dates that were newer. Otherwise, many of Leopard's components are older than the development builds.
 
Hi guys,

I have some interesting news.
I retested the DVD Player app from SL_PPC after the "graphics fix"
Now the DVD Player app works perfectly using the framework from SL_PPC
so no need anymore to get the Leopard Version and it's dvd playback framework.

Best regards,
voidRunner
 
Hello!
Great work on this so far. Has anyone gotten wireless working on any of the PowerBook G4s? One could assume that a kext file from Leopard ought to work if installed properly?
I have a 15” 1.25GHz PowerBook G4 that it is not recognized on and is currently stuck on a grey screen after the initial setup which I was able to go through once it was connected to Ethernet.
I’ve only owned two Macs brand new, this PowerBook and the G3 400MHz iMac it replaced. A little bit of vintage newness is pretty cool!
 
Evening update,

Well, I'm sort of back to the beginning. I've restored a fresh copy of the SL_PPC image to tinker with, but so far, in my latest attempt, just moving over the PPC compatible files from the Snow Leopard Release DVD from /usr/bin, /usr/sbin/, and /usr/libexec, Mac OS won't boot. It's probably "libexec" since the others seem to be more core UNIX utilities, but I don't know. I also know as I tinker, it throws up lots of permission errors and my attempts to fix them don't seem to work (BATchMOD included).
 
I can confirm that compiling from the Open-source Apple code does indeed add/restore functionality in these developer builds. I’ve just compiled and installed the version of cups from 10.6.0 on 10A190 and it’s working - my printer panel now gracefully opens instead of crashing system preferences! I’m optimistic moving forward.
 
I can confirm that compiling from the Open-source Apple code does indeed add/restore functionality in these developer builds. I’ve just compiled and installed the version of cups from 10.6.0 on 10A190 and it’s working - my printer panel now gracefully opens instead of crashing system preferences! I’m optimistic moving forward.

Alright!
 
  • Like
Reactions: Windreader
Evening update,

Well, I'm sort of back to the beginning. I've restored a fresh copy of the SL_PPC image to tinker with, but so far, in my latest attempt, just moving over the PPC compatible files from the Snow Leopard Release DVD from /usr/bin, /usr/sbin/, and /usr/libexec, Mac OS won't boot. It's probably "libexec" since the others seem to be more core UNIX utilities, but I don't know. I also know as I tinker, it throws up lots of permission errors and my attempts to fix them don't seem to work (BATchMOD included).
Before tinkering with the permissions and if doing so to a target-mode attached drive on another system: Make sure you have set the whole drive (info, then bottom-most checkmark) to toggle "ignore ownership on this drive".
Always test the "stickiness" of the attributes after setting them by just re-dropping files to i.e. BatChmod again.

Bildschirmfoto 2020-05-22 um 09.19.16.jpg

[automerge]1590132419[/automerge]
Hello!
Great work on this so far. Has anyone gotten wireless working on any of the PowerBook G4s? One could assume that a kext file from Leopard ought to work if installed properly?
I have a 15” 1.25GHz PowerBook G4 that it is not recognized on and is currently stuck on a grey screen after the initial setup which I was able to go through once it was connected to Ethernet.
I’ve only owned two Macs brand new, this PowerBook and the G3 400MHz iMac it replaced. A little bit of vintage newness is pretty cool!
Yes, some combinations of builds (A96 and A190) on various PBs does indeed show airport functionality. See earlier posts...
Grey screen: If you at least have mouse pointer on that, try clicking in the region where login prompt would normally be. Enter password (listen to bonks as audio output as indication of rejection of keystrokes, then press Enter.
Helped me once on a new setup. Never occurred again after that hiccup.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.