Booting from AHCI SSD's on PowerPC using a redirect?

[DearthnVader]

I have not tried to do this myself, but it should be theoretically possible as far as I know.

We should be able to boot Mac OS X versions that have support for generic AHCI protocol disk drives and controllers if we load the root file system from a copy on a supported boot drive then redirect the root and user file system on the AHCI drive to be the one that gets mounted as "/".

The boot loader( BootX ) and the kernel along with the extensions and caches would all be loaded into RAM from a supported boot disk, but the redirect would be used by that system in RAM to mount the AHCI SSD as "/" Root/User.

Also, we should be able to put the root file system for Linux on a supported boot drive yet have it mount an installed User partition on an AHCI SSD.

There may also be, or we could create a module for GRUB2 that would support AHCI. I've never looked into that. From memory some PowerPC Mac's can use GRUB( ELF ) as a boot loader rather than yaboot( :tbxi( a XCOFF boot loader wrapped in an XML script ).

XPostFacto had a "Helper Disk" function that did pretty much what we want to do to allow booting Mac OS X from a PCI Firewire card that didn't have any Open Firmware drivers to support "Native Boot" on PPC.

Tho I've used this "Helper Disk" function many times I've never really looked at what are it work and I think some users have tried it to boot from AHCI and it failed. So Let's figure out why it's failing if we can.

Also, I used a disk image with BootX with Openbios and Qemu-system-PPC with a bunch of redirect commands for Open Firmware to specify the disk to load the kernel and extensions from. Tho I've forgotten how most of that worked, and Openbios had native support to read and boot from that disk, so of that maybe useful here, and it won't take me long to refresh my memory on how exactly that worked.

One of the main benefits of XPF was it would keep the root system files up to date between the copies on the supported boot disk and that of the unsupported root file system we mount from RAM after the AHCI drivers are loaded.

Of course all this is very similar to how a Chroot works on *nix.

It won't really help with boot times, may even slow them down, but it should allow us to have very speedy AHCI SSD's in use for file system operations.

 

[joevt]

I just finished building XPostFacto on my Quad G5 in Tiger. I'll update my GitHub when I finish testing the result on my Power Mac 8600. My changes aren't really necessary for what you're talking about but we could use it as a base.

Anyway, I think XPostFacto is supposed to be able to work on New World Macs as well? I haven't tried it though. Instead of a RAM disk, the helper disk is a partition on a bootable disk.

The XPostFacto UI shows what the nvram settings will be so you can see what is required to redirect the root. In the attached screenshot from my Quad G5, boot-device points to BootX on the helper disk (internal SATA disk) which also contains the startup kernel extensions. boot-args contains the root device path which is a FireWire partition - you'll point this at the AHCI SSD. I suppose if someone made a XHCI driver or an NVMe driver for PPC Mac OS X (both have been done before for Intel Mac OS X) then you could point it at a USB 3.x drive or an NVMe SSD.

To remove the need of a helper disk, you would need to make an Open Firmware driver and have a method to load that. The Open Firmware driver could be in a PCI expansion ROM such as for a GPU or SATA controller, or it could be loaded from disk (from a file for New World Macs, or from a partition for Old World Macs), or it could be added to the Mac's ROM (we know how to extract FCode images from Old World and New World ROM's, and how to modify and create FCode images, but we don't know exactly how to add them to a Mac ROM - maybe we know enough but an attempt has not been made).

 

[ifrit05]

AFAIK, OS X sets up a redirect when using a RAID array. Might be good to look at how OS X sets up a redirect instead of using a/an (outdated) 3rd party utility?

 

[DearthnVader]

AFAIK, OS X sets up a redirect when using a RAID array. Might be good to look at how OS X sets up a redirect instead of using a/an (outdated) 3rd party utility?

I think they do essentially the same thing. XPF just leverages Apple's built-in way of redirecting that they put in to boot from RAID volumes.

We just have to see if we can figure out why it doesn't seem to work with AHCI and Leopard.

 

[joevt]

I think they do essentially the same thing. XPF just leverages Apple's built-in way of redirecting that they put in to boot from RAID volumes.

The RAID driver seems to include an Open Firmware component which is stored as one of the OS 9 driver partitions with a RAID driver.
https://github.com/apple-oss-distri...ces/Apple_Driver_OpenFirmware.0x00000000.drvr

We just have to see if we can figure out why it doesn't seem to work with AHCI and Leopard.

Did you check that the helper includes the AHCI driver kexts? And that the kexts load and attach to the AHCI device to the I/O registry? And the partitions get added to the I/O registry? When that happens then the kernel will stop waiting for root device (if the redirect path actually matches the path of the AHCI device and partition).

 

[DearthnVader]

Did you check that the helper includes the AHCI driver kexts? And that the kexts load and attach to the AHCI device to the I/O registry? And the partitions get added to the I/O registry? When that happens then the kernel will stop waiting for root device (if the redirect path actually matches the path of the AHCI device and partition).

Sadly I just don't have the hardware, no PCI-E PPC Mac's, and I don't think a ACHI compatible PCI controller was ever made.

At some point I may get a PCI to PCI-E adapter to try with, but so many hacks, so little time.

 

[barracuda156]

I just finished building XPostFacto on my Quad G5 in Tiger. I'll update my GitHub when I finish testing the result on my Power Mac 8600. My changes aren't really necessary for what you're talking about but we could use it as a base.

Anyway, I think XPostFacto is supposed to be able to work on New World Macs as well? I haven't tried it though. Instead of a RAM disk, the helper disk is a partition on a bootable disk.

The XPostFacto UI shows what the nvram settings will be so you can see what is required to redirect the root. In the attached screenshot from my Quad G5, boot-device points to BootX on the helper disk (internal SATA disk) which also contains the startup kernel extensions. boot-args contains the root device path which is a FireWire partition - you'll point this at the AHCI SSD. I suppose if someone made a XHCI driver or an NVMe driver for PPC Mac OS X (both have been done before for Intel Mac OS X) then you could point it at a USB 3.x drive or an NVMe SSD.

To remove the need of a helper disk, you would need to make an Open Firmware driver and have a method to load that. The Open Firmware driver could be in a PCI expansion ROM such as for a GPU or SATA controller, or it could be loaded from disk (from a file for New World Macs, or from a partition for Old World Macs), or it could be added to the Mac's ROM (we know how to extract FCode images from Old World and New World ROM's, and how to modify and create FCode images, but we don't know exactly how to add them to a Mac ROM - maybe we know enough but an attempt has not been made).

View attachment 2116189

Did you eventually give it a try?

 

[joevt]

Did you eventually give it a try?

Nope. It will be awhile before I get back to it.

 

[barracuda156]

Nope. It will be awhile before I get back to it.

I see. Thanks.