Snow Leopard on Unsupported PowerPC Macs

[flyproductions]

If it is in the kernel, we are out of luck, at least until someone rebuilds a newer kernel for 10A190.

Was AHCI with Snow Leo on INTEL bootable?

 

[Amethyst1]

Was AHCI with Snow Leo on INTEL bootable?

On 10.6.8, with the SSUBX (SM951): yeah! Or do you mean in 10A96/10A190?

All Intel Macs use AHCI for their internal SATA ports (exception: the original MacBook Air uses a PATA hard drive or PATA SSD), so these have to work in Tiger 10.4.4 and later versions... on Intel Macs.

I'm planning to set up Leopard 10.5.0 on a MacBook Pro and then step through 10.5.1, 10.5.2, ... to find the oldest version of the OS and AHCI kexts that will talk to and boot from external AHCI blades. This might tell us something.

 

[ifrit05]

On 10.6.8, with the SSUBX (SM951): yeah! Or do you mean in 10A96/10A190?

All Intel Macs use AHCI for their internal SATA ports (exception: the original MacBook Air uses a PATA hard drive or PATA SSD), so these have to work in Tiger 10.4.4 and later versions... on Intel Macs.

I'm planning to set up Leopard 10.5.0 on a MacBook Pro and then step through 10.5.1, 10.5.2, ... to find the oldest version of the OS and AHCI kexts that will talk to and boot from external AHCI blades. This might tell us something.

Wait, what IS the difference between AHCI and SATA? I thought SATA automatically infers AHCI. Do the G5's not use AHCI???

 

[Amethyst1]

Wait, what IS the difference between AHCI and SATA?

SATA is a physical interface. AHCI is a logical interface/protocol that can be used with SATA controllers/drives and also (early) native PCIe SSDs. An OS that has an AHCI driver can talk to these controllers without relying on a specific driver.

I thought SATA automatically infers AHCI.

Not necessarily. On PCs, you can or could switch the southbridge's SATA controller between non-AHCI (“legacy”) and AHCI mode, the former being for OSes that don’t have an AHCI driver.

Do the G5's not use AHCI???

No. PPC versions of OS X prior to Leopard don’t even have an AHCI driver AFAIK (Tiger on Intel needs to, of course).

 

[ifrit05]

No. PPC versions of OS X prior to Leopard don’t even have an AHCI driver AFAIK (Tiger on Intel needs to, of course).

Wait, so what do our G5s use as the protocol if they don't use AHCI? Do they run it in legecy mode? If so what was the advantage of using SATA back then?

 

[Amethyst1]

Wait, so what do our G5s use as the protocol if they don't use AHCI? Do they run it in legecy mode?

Intel's AHCI specification is separate from SATA, so you can have a perfectly functional SATA controller without support for AHCI. Such a controller will require specific drivers to work. OS X has those for the G5's southbridges.

"Legacy mode" (or "IDE emulation mode") is a term used with PCs to indicate the SATA controller built into the southbridge will pretend to be an oldschool IDE controller. Non-AHCI-aware OSes can then talk to it it using their built-in IDE driver so you don't need to load a specific driver for the SATA controller. This ensures that peeps can install e.g. XP on a SATA drive without running into a nasty INACCESSIBLE_BOOT_DEVICE crash they might not know how to solve.

If so what was the advantage of using SATA back then?

Point-to-point connections, no jumpers, thinner cables, higher maximum transfer rates, being cutting edge in 2003. Running a SATA controller in non-AHCI mode doesn't make it as slow as IDE or anything.

 

[B S Magnet]

If it is in the kernel, we are out of luck, at least until someone rebuilds a newer kernel for 10A190.

Indeed. It would, however, surprise me for Apple to include kernel-level support for AHCI across all of Leopard and Snow Leopard, but not for interim builds of Snow Leopard (which was prioritized from the outset to run on Intel-based Macs).

 

[Amethyst1]

Indeed. It would, however, surprise me for Apple to include kernel-level support for AHCI across all of Leopard and Snow Leopard, but not for interim builds of Snow Leopard (which was prioritized from the outset to run on Intel-based Macs).

It’s more likely that the AHCI driver in those early Snowy builds — like the one in Tiger for Intel — doesn’t like external AHCI controllers for some reason. Which is why I’m interested in seeing if earlier versions of Leo are equally picky.

 

[B S Magnet]

It’s more likely that the AHCI driver in those early Snowy builds — like the one in Tiger for Intel — doesn’t like external AHCI controllers for some reason. Which is why I’m interested in seeing if earlier versions of Leo are equally picky.

In other words, your working hypothesis here is the Apple versions of AHCI SSDs (like SSUAX, SSUBX, etc.) might work where others might not?

 

[Amethyst1]

In other words, your working hypothesis here is the Apple versions of AHCI SSDs (like SSUAX, SSUBX, etc.) might work where others might not?

If we’re unlucky only the built-in SATA ports in Intel Macs work, but no PCIe SATA cards… and no PCIe SSDs either. Even if using Apple’s version of an SSD, its controller is still made by e.g. Samsung in the case of the SSUAX and SSUBX.

 

[B S Magnet]

If we’re unlucky only the built-in SATA ports in Intel Macs work, but no PCIe SATA cards… and no PCIe SSDs either. Even if using Apple’s version of an SSD, its controller is still made by e.g. Samsung in the case of the SSUAX and SSUBX.

This makes me want to find a 2008-era MacBook Air and to try running one of the SL-PPC builds on it. As I understand it, these would require the AHCI translation layer, yes?

 

[pc297]

I have added support for old systems here, and it sorta automates the process: https://ports.macports.org/port/R-app/details/
Unfortunately, on 10.6 PPC for an unclear reason it fails to compile 1 xib file when done this way, so it won’t work now. Given that it does build outside of Macports, it is fixable. I will try to get back to fixing that soon.
As of now, anyone wishing to build R-app on 10.6 PPC may either do the whole thing manually or do sudo port patch R-app and then copy build directory somewhere – and just build with Xcode.

I do not really remember which version built without replacing xibs now. It was something of 1.6x.

R builds quite fast on G5. Definitely less an hour, I think about 30 min. Need to try. gcc takes around 3+ hrs for a single arch in Macports. If you hack stage 1 flags, can be built faster, like 2.5 hrs (this is on Quad).

Thanks a lot for that; R GUI 1.72 seems to work, I did get 1.73 to compile and work on El Cap however indeed with minor bugs too (notably exiting with status 0 when either having a typo in the package name with library() or trying a missing one).

Most things seem to work but with R 4.X under old versions of Darwin such as under SL (and El Cap too) all calls to CLOCK_MONOTONIC will fail as this is unsupported <10.12. I had tried setting -D_POSIX_C_SOURCE=199309L as compile flags (also in .R/Makevars) but to no avail. However a workaround in the source of the R packages (and other sources that use it obviously) is as follows:

#ifdef __APPLE__
#include <sys/types.h>
#include <sys/_types/_timespec.h>
#include <mach/mach.h>
#include <mach/clock.h>
#include <mach/mach_time.h>

#ifndef mach_time_h
#define mach_time_h
#ifndef CLOCK_MONOTONIC
#define CLOCK_MONOTONIC SYSTEM_CLOCK
#endif // CLOCK_MONOTONIC

static void clock_gettime(int clk_id, struct timespec *tp) {
        clock_serv_t cclock;
        mach_timespec_t mts;
        host_get_clock_service(mach_host_self(), SYSTEM_CLOCK, &cclock);
        //retval = clock_get_time(cclock, &mts);
        mach_port_deallocate(mach_task_self(), cclock);
        tp->tv_sec = mts.tv_sec;
        tp->tv_nsec = mts.tv_nsec;
}
#endif /* mach_time_t */
#endif /* __APPLE__ */

from

proxysql/include/gen_utils.h at v1.4.10 · sysown/proxysql

High-performance MySQL proxy with a GPL license. Contribute to sysown/proxysql development by creating an account on GitHub.

github.com

There might be a way to patch <sys/time.h> directly to avoid to have to patch the source codes of the various packages involved, but this approach a la Mac Gyver seems to work; I was able to build later_1.30 which required it for example (and then ultimately Seurat 4.0)

Regarding the status 0 exit on wrong lib name, did you get this too, and if so did you manage to fix it?

Cheers,

 

[pc297]

I have added support for old systems here, and it sorta automates the process: https://ports.macports.org/port/R-app/details/
Unfortunately, on 10.6 PPC for an unclear reason it fails to compile 1 xib file when done this way, so it won’t work now. Given that it does build outside of Macports, it is fixable. I will try to get back to fixing that soon.
As of now, anyone wishing to build R-app on 10.6 PPC may either do the whole thing manually or do sudo port patch R-app and then copy build directory somewhere – and just build with Xcode.

I do not really remember which version built without replacing xibs now. It was something of 1.6x.

R builds quite fast on G5. Definitely less an hour, I think about 30 min. Need to try. gcc takes around 3+ hrs for a single arch in Macports. If you hack stage 1 flags, can be built faster, like 2.5 hrs (this is on Quad).

Slightly offtop question, do you know of any way to automatically enable binary package download on 1.72 / R 4.X (for intel machines, obviously there haven't been ppc binaries for a long time), as under e.g. R 3.6.3? R 4.X/R-app 1.72 seem to default to source even though most binaries do seem to work with it (but not all), install.packages defaults to source and the "CRAN (binaries)" and "BioConductor (binaries)" drop-down options are greyed-out with 1.72 (which they weren't with 1.70 and R 3.6.3)

 

[Amethyst1]

This makes me want to find a 2008-era MacBook Air and to try running one of the SL-PPC builds on it. As I understand it, these would require the AHCI translation layer, yes?

The “early 2008” doesn’t because the drive is hanging off the PATA bus. The “late 2008” does.

 

[barracuda156]

Thanks a lot for that; R GUI 1.72 seems to work, I did get 1.73 to compile and work on El Cap however indeed with minor bugs too (notably exiting with status 0 when either having a typo in the package name with library() or trying a missing one).

Most things seem to work but with R 4.X under old versions of Darwin such as under SL (and El Cap too) all calls to CLOCK_MONOTONIC will fail as this is unsupported <10.12. I had tried setting -D_POSIX_C_SOURCE=199309L as compile flags (also in .R/Makevars) but to no avail. However a workaround in the source of the R packages (and other sources that use it obviously) is as follows:

#ifdef __APPLE__
#include <sys/types.h>
#include <sys/_types/_timespec.h>
#include <mach/mach.h>
#include <mach/clock.h>
#include <mach/mach_time.h>

#ifndef mach_time_h
#define mach_time_h
#ifndef CLOCK_MONOTONIC
#define CLOCK_MONOTONIC SYSTEM_CLOCK
#endif // CLOCK_MONOTONIC

static void clock_gettime(int clk_id, struct timespec *tp) {
        clock_serv_t cclock;
        mach_timespec_t mts;
        host_get_clock_service(mach_host_self(), SYSTEM_CLOCK, &cclock);
        //retval = clock_get_time(cclock, &mts);
        mach_port_deallocate(mach_task_self(), cclock);
        tp->tv_sec = mts.tv_sec;
        tp->tv_nsec = mts.tv_nsec;
}
#endif /* mach_time_t */
#endif /* __APPLE__ */

from

proxysql/include/gen_utils.h at v1.4.10 · sysown/proxysql

High-performance MySQL proxy with a GPL license. Contribute to sysown/proxysql development by creating an account on GitHub.

github.com

There might be a way to patch <sys/time.h> directly to avoid to have to patch the source codes of the various packages involved, but this approach a la Mac Gyver seems to work; I was able to build later_1.30 which required it for example (and then ultimately Seurat 4.0)

Regarding the status 0 exit on wrong lib name, did you get this too, and if so did you manage to fix it?

Cheers,

You may try using legacysupport PG. I am not sure it can work directly (unless you write portfiles for R packages, like FreeBSD did), but you can manually add needed header and ldflag.

In portfiles CLOCK_MONOTONIC is as easy as (second line is optional):

PortGroup legacysupport 1.1
legacysupport.newest_darwin_requires_legacy 15

See: https://github.com/macports/macports-legacy-support

P. S. I would expect -D_POSIX_C_SOURCE to break things on macOS. -D_DARWIN_C_SOURCE is the correct cppflag to enable some Apple-specific extensions.

 

[barracuda156]

This makes me want to find a 2008-era MacBook Air and to try running one of the SL-PPC builds on it. As I understand it, these would require the AHCI translation layer, yes?

I am probably saying the obvious, but you can install SL-PPC in VM.

 

[B S Magnet]

I am probably saying the obvious, but you can install SL-PPC in VM.
View attachment 2122628

Yes, but could a VM replicate the hardware conditions of a late 2008 MBA?

I have no doubt there are possibly dozens of variables one could configure in a VM like VMware or Parallels in which SL-PPC would run fine. For the kind of testing I prefer to do, working with the actual gear is a priority, in that doing so it leaves little room for doubt when a component, bus, or hardware configuration works or fails.

 

[Amethyst1]

This makes me want to find a 2008-era MacBook Air and to try running one of the SL-PPC builds on it.

A problem you may run into when testing on a late-2008 is that ‘96 is a few months older than the MBA while ‘190 was released at or around the same time.

That being said, what would a 2008 MBA offer as a SL-PPC test mule?

 

[pc297]

The “early 2008” doesn’t because the drive is hanging off the PATA bus. The “late 2008” does.

What about the Mac Pro (all versions should support PCIe AHCI blades, including booting off of them, including the 1,1-2,1, right)?

The Mac Pro 3,1, 4,1 and 5,1 (for the latter two the latest firmware updates allow the use of NVMe SSDs) can run SL: 10.6 for 4,1 10.6.4 for the 2010 5,1 and "partial" SL support for the 2012 5,1), however it turns out that all versions of the 5,1 might actually support earlier versions of 10.6:

Installing OSX Snow Leopard on a 2012 Mac Pro 5,1 | Allie Mars

How to install OS X Snow Leopard on a 2012 Mac Pro 5,1 computer - and yes, it works!

www.alliemars.com

The question is whether the latter two will boot "unsupported" versions of SL off of an AHCI PCIe SSD. Does anyone know if the MP 1,1-2,1 could boot 10.4-10.5 off an AHCI PCIe blade already, or the 3,1 and 4,1 10.5 (which in all cases would mean that AHCI support was brought in as intel-specific prior to SL)?

Btw it's also possible to boot SL off an NVMe SSD if I understood this correctly on the 3,1 but a long shot :

Mac Pro 3,1 NVMe support + Upgrade Guide + Questions

Hello everybody! I'm newly owner of MP 3,1 and I want to discuss upgrading of this nice but old machine with you. I suggest everyone to take part in creating this guide. Now I will post my achievement in making it bootable from NVMe SSD. Bootable NVMe Note: it can be dangerous for your MP...

forums.macrumors.com

As for 10A190 I have personally booted it on the MP 2,1 (for which afaik there is no NVMe SSD solution but if someone knows a way I'd be thrilled) but not off an AHCI blade and not yet on the 5,1, will give it a try and let you guys know

Btw tried to run SL off an USB hard drive with SL on it on a MBP 2014 Retina (which has an AHCI PCIe SSD), and it obviously didn't make it past kextload

 

[Amethyst1]

What about the Mac Pro (all versions should support PCIe AHCI blades, including booting off of them, including the 1,1-2,1, right)?

Right. All Mac Pros can boot from AHCI blades.

Does anyone know if the MP 1,1-2,1 could boot 10.4-10.5 off an AHCI PCIe blade already, or the 3,1 and 4,1 10.5 (which in all cases would mean that AHCI support was brought in as intel-specific prior to SL)?

We need to differentiate between AHCI support for the internal SATA controllers in Intel Macs and AHCI support for external PCIe SATA controllers or AHCI PCIe blades.

• 10.4 and older versions on PPC do not support AHCI devices at all.
• 10.4.4 through 10.4.11 on Intel do not support “external” AHCI devices, only internal SATA controllers.
• 10.5.8 supports internal and external AHCI devices on both Intel and PPC. It thus recognises PCIe SATA controllers and PCIe AHCI blades in PCIe G5s and Mac Pros.

See below for notes on Leopard versions prior to 10.5.8.

Btw it's also possible to boot SL off an NVMe SSD if I understood this correctly on the 3,1 but a long shot :

SL doesn't support NVMe. Better forget about NVMe unless you run High Sierra or a newer version. Or Yosemite, if you use an Apple NVMe blade.

Btw tried to run SL off an USB hard drive with SL on it on a MBP 2014 Retina (which has an AHCI PCIe SSD), and it obviously didn't make it past kextload

You need at least a pached mach_kernel to prevent panicking due to the Haswell CPU.

As for 10A190 I have personally booted it on the MP 2,1 (for which afaik there is no NVMe SSD solution but if someone knows a way I'd be thrilled) but not off an AHCI blade and not yet on the 5,1, will give it a try and let you guys know

I'm 99.999999% sure it will panic on the MacPro5,1 due to the CPU(s) being way too new — and due to the AHCI blade, if you have one.

Which is why I’m interested in seeing if earlier versions of Leo are equally picky.

Well, they sure are. I tested with an SSUBX blade attached to a 2007 MacBook Pro using an ExpressCard-to-PCIe adapter.

• 10.5.0 up to and including 10.5.5 kernel-panic due to AppleACPIPort.kext and IOAHCIFamily.kext.
• 10.5.6 and 10.5.7 do not panic, but do not recognise the blade either. (Note: 10.6.8 behaves the same so it may be an issue with the ExpressCard setup. 10.6.8 on a 2011 MacBook Pro recognises and boots off the blade just fine via Thunderbolt.)

Given that 10A96 and 10A190 are both older than 10.5.6, it's not surprising that they crap their pants too.

 

[barracuda156]

Slightly offtop question, do you know of any way to automatically enable binary package download on 1.72 / R 4.X (for intel machines, obviously there haven't been ppc binaries for a long time), as under e.g. R 3.6.3? R 4.X/R-app 1.72 seem to default to source even though most binaries do seem to work with it (but not all), install.packages defaults to source and the "CRAN (binaries)" and "BioConductor (binaries)" drop-down options are greyed-out with 1.72 (which they weren't with 1.70 and R 3.6.3)

Sorry, no idea. On PPC installing from source is the only option.

You may try RStudio, it can probably be built on 10.6 Intel.

 

[Amethyst1]

The question is whether the latter two will boot "unsupported" versions of SL off of an AHCI PCIe SSD.

If by “unsupported” you mean 10A96 and 10A190, they’ll crap their pants at the sight of “external” AHCI controllers (SATA cards or PCIe blades, doesn’t matter). And I don’t see the point of running these on Intel when you can just run 10.6.8 tbh.

 

[B S Magnet]

If by “unsupported” you mean 10A96 and 10A190, they’ll crap their pants at the sight of “external” AHCI controllers (SATA cards or PCIe blades, doesn’t matter). And I don’t see the point of running these on Intel when you can just run 10.6.8 tbh.

Your working hypothesis is there are kernel-level instructions involved here which cannot be overridden by a swapping of kexts and other components, correct?

 

[Amethyst1]

Your working hypothesis is there are kernel-level instructions involved here which cannot be overridden by a swapping of kexts and other components, correct?

I checked the versions of AppleAHCIPort.kext and IOAHCIFamily.kext as I stepped through the 10.5.x updates. I think it’s (just?) a matter of having sufficiently new versions of both kexts — such as those from 10.5.8, which is known to work with external AHCI controllers — but these may depend on other kexts or kernel-level features not found in ‘96 or ‘190 as you say, which is why swapping them over doesn’t work.

Since my (Samsung) blade isn’t recognised via ExpressCard even in 10.6.8 which is known to take to it, the fact that 10.5.6 and 10.5.7 don’t panic doesn’t prove anything with regards to their willingness to take to it. I guess testing with a PCIe G5 or Mac Pro is necessary for conclusive results.

 

[pc297]

10.5.8 supports internal and external AHCI devices on both Intel and PPC. It thus recognises PCIe SATA controllers and PCIe AHCI blades in PCIe G5s and Mac Pros.
See below for notes on Leopard versions prior to 10.5.8.

But G5s can't boot off of them? Or can they?