Support for patching bootloader to enable AHCI support in Macintoshes


New Member
With some Intel Macs, AHCI mode is disabled for BIOS emulation modes so that Windows XP will install without needing a driver disk. Unfortunately Apple does not provide a method to turn AHCI support on later.

In legacy mode, transfers are capped at 133MB/s (SSDs suffer greatly from this), it also disables the fifth and sixth SATA port on Mac Pros, and features like hotplug, trim, and (I think) NCQ don't work.

Bypassing the BIOS emulation by loading windows via EFI doesn't work well, because Apple's EFI was created before UEFI, so the two don't really mix.

The solution to enabling AHCI at boot time for any BIOS-booted OS is to set the SATA controller's PCI register each time you boot, prior to booting the OS. With grub2, this can be done with 'setpci'. There are also a few shell scripts and an OSX tool that can be used to patch the windows standard MBR. Further reading can be done at for example this InsanelyMac post and utilities for enabling AHCI in BIOS emulation mode.

Each chipset has a different device ID (obviously) and also a different register that needs setting. Here are a list of a few common ones (in the format accepted by setpci) that could be added in a dropdown, but even simply having a section or configuration file setting for picking your own device and register would be great.
  • MacPro1,1 (2006) intel 631xESB/632xESB chipset: setpci -d 8086:2680 90.b=40
  • MacBookPro5,2 (mid 2009) with MCP79 chipset: setpci -d 10de:0ab5 9c.b=06
  • MacBookPro6,2 intel 3400 chipset: setpci -d 8086:3b28 90.b=60
The least-technical way to add this to the boot process would be to load grub2 from the BCD, do the setpci, and then load whatever OS directly from there.

The cleaner way that requires a bit of assembly would be to patch the MBR or drive's bootsector itself so that this is done before bootmgr is loaded, bypassing the need for grub etc. Unfortunately all the existing patches floating around on the net are for each specific controller. I don't have time to disassemble one and see if you could just swap the PCI IDs and registers and redo the patch, but it seems fairly likely.

As it stands the way this is accomplished with EasyBCD is by chaining grub2. this isn't too bad but it would be wonderful if EasyBCD could do it natively.



Mostly Harmless
Staff member
Hi projct,

Interesting proposition. I can see a few different ways of pulling this off, but as you say, going the GRUB or GRUB2 route seems to be the easiest. I'll think this over and see what can be done.


Mostly Harmless
Staff member
I've been giving this some thought - it's not something that belongs in EasyBCD, but I could write up a bootmgr patcher that can do this dynamically. I don't know how much demand there is for something like this, though?


New Member
Every Mac on the market currently requires a variation of this trick in order to get AHCI to work outside of OSX. Spinning drives are already able to exceed 133MB/s sequential read, and the other solutions available cannot be used inside Windows. I suppose it's up to you as to whether you'd think it's worth it :smile:

Sidenote: you'd have to include a note in a readme for a project like this explaining that there is a registry edit that has to be done to tell the microsoft AHCI driver to load on next boot, otherwise a successful patch results in a BSOD when it can't find the boot device.

I've installed SSDs in one of every ten Mac clients I've had this year (40 of 400ish) and for at least 15 of them I've had to set up grub2 for their bootcamp instals. I don't expect that number to go down anytime soon, and even if apple changes their EFI for windows 8 or something, they don't add functionality to older machines' EFI so there'll always be a sizable number of Macs that require this. A windows patcher (particularly one that lets you specify which device, register, and value to set) would turn a 15 minute-ish ordeal of booting a linux livecd and mucking about with grub into importing a registry entry and running the tool.

Most importantly, since there are situations (e.g. upgrading windows or installing other OSes) that can muck about with the bootloader it would leave a fairly easy method to re-do the patch after something has reverted it. :smile:

Whether you choose to work on it or not, thanks for thinking it over, at least :smile: