BiosBlockIO: Fix for Clover recognizing non-Intel SATA controlled Drives

[potatohead113]

I just discovered this and wanted to share. Clover wasn't seeing any drives attached to my Apricorn Velocity Solo X2 (currently the fastest SATA3 PCIe card for my x58 motherboard), which uses the Marvell 9182 controller. I then noticed this on the Clover Installation Wiki (https://clover-wiki.zetam.org/Installation):

"Additionally there is a BiosBlockIO option. This is a CloverEFI-64 variant with a special boot7 file targeted for computers with a non-standard SATA controller. This driver operates through the BIOS and usually works with any controller (as the BIOS needs to support them!). However it not always works, for instance with the Dell Inspiron 1525."

I tried it and it worked! So here's the tip:

To boot with a Marvell SATA controller (such as the Marvell 9182 on a Apricorn Velocity Solo X2), I updated ("upgraded") Clover with CloverEFI>Clover EFI 64-bits BiosBlockIO. See attached screenshot. After Rebooting, Clover should now effortlessly see any volumes mounted on this controller-- in fact I think it boots a bit faster.

Note: I am using a Legacy Root installation of Clover.

I hope this helps someone else unable to get some of their SATA drives to appear in Clover.

 

[AnArChYm]

I have a Rampage III Black Edition with the x58 chipset and by default it has the Marvell Sata6G 9182 controller. However when I tried to option above (BiosBlockIO) I can't manage to arrive up to the Clover menu...It basically fails on init7 and then throws an error like the following:

b1f: init
b1f: error

Anyone has any ideas on how to be able to boot from the Marvell controller rather than the ICH10R (intel SataII controller)?

P.S. The Marvell controller is set to AHCI in BIOS, and I am able to see other drives /volumes (connected to the Marvell controller) once I boot in El Capitan.

Edit: Don't know whether the following is relevant, the other drive currently connected on the second Marvel 6G Sata controller is an SSD having a dual boot Windows 8 & Mac 10.9.5 using Chameleon bootloader. Could this be inflicting problems for the BiosBlockIO while Clover is scanning the volumes?

The only way to have the drives connected to the Marvell 6G Sata Controller and Clover recognizes them is by changing the Controller type from AHCI to IDE, but then obviously El Capitan wont be able to boot, since MAC OS X is not able to read IDE devices

 

[kissandtellMAC74]

I have a Rampage III Black Edition with the x58 chipset and by default it has the Marvell Sata6G 9182 controller. However when I tried to option above (BiosBlockIO) I can't manage to arrive up to the Clover menu...It basically fails on init7 and then throws an error like the following:

b1f: init
b1f: error

Anyone has any ideas on how to be able to boot from the Marvell controller rather than the ICH10R (intel SataII controller)?

P.S. The Marvell controller is set to AHCI in BIOS, and I am able to see other drives /volumes (connected to the Marvell controller) once I boot in El Capitan.

Edit: Don't know whether the following is relevant, the other drive currently connected on the second Marvel 6G Sata controller is an SSD having a dual boot Windows 8 & Mac 10.9.5 using Chameleon bootloader. Could this be inflicting problems for the BiosBlockIO while Clover is scanning the volumes?

The only way to have the drives connected to the Marvell 6G Sata Controller and Clover recognizes them is by changing the Controller type from AHCI to IDE, but then obviously El Capitan wont be able to boot, since MAC OS X is not able to read IDE devices

Same problem here on x58 MSI Board and SATA 3 PCIe cards, but on different Marvell controller except that I don't get b1f: init or b1f: error, just a black screen with a non-blinking white cursor up on the left. I had non problem with Chameleon Enoch version though (but problem is with Nvidia Web driver not loading).

 

[scoliosis]

I just used this to boot into a FusionMPT SAS controller and it worked great. However when I use this method to boot Clover, the kexts are not being loaded. Any idea what's up with that?

 

[potatohead113]

I just used this to boot into a FusionMPT SAS controller and it worked great. However when I use this method to boot Clover, the kexts are not being loaded. Any idea what's up with that?

Does that mean it's not injecting FakeSMC too (and thus you can't get into OS X?) If so, I'm having this problem too, not sure when it started, but specifically, I get the following, fairly generic error message with -v which I presume is because it's not injecting FakeSMC?:

busy timeout [1], (60s), kesxtd wait (0): "AppleACPICPU"

before it reboots. Thus I can no longer get into OS X. I wonder if it's related to your query?

 

[scoliosis]

Does that mean it's not injecting FakeSMC too (and thus you can't get into OS X?) If so, I'm having this problem too, not sure when it started, but specifically, I get the following, fairly generic error message with -v which I presume is because it's not injecting FakeSMC?:

busy timeout [1], (60s), kesxtd wait (0): "AppleACPICPU"

before it reboots. Thus I can no longer get into OS X. I wonder if it's related to your query?

Figured it out. So it turns out, if you Multibeast it then immediately upgrade Clover (to install the BIOS interrupt bootloader) it mucks up the config.plist. However, what you really need is just get a copy of "boot" binary in the EFI partition that is "mode 7" enabled. So what I did was mount the EFI partition of my mucked up macOS install. Copy out the "boot" binary from there (since it is BiosBootBlock enabled) onto the Unibeast created USB installer. Erase the EFI partition and macOS partitions. Boot off the Unibeast created installer and install per normal. Now when you reboot after the install, the USB installer will find the SAS attached drive and you can boot into it. Install Multibeast per usual. But once completed, before you reboot, replace the "boot" binary in the EFI partition from the one in the USB stick. You're good to go after that.

FakeSMC is injected properly for me, but anything after that fails (once the SAS driver loads).

Although yours looks more like the Power management kext is failing.

 

[potatohead113]

Figured it out. So it turns out, if you Multibeast it then immediately upgrade Clover (to install the BIOS interrupt bootloader) it mucks up the config.plist. However, what you really need is just get a copy of "boot" binary in the EFI partition that is "mode 7" enabled. So what I did was mount the EFI partition of my mucked up macOS install. Copy out the "boot" binary from there (since it is BiosBootBlock enabled) onto the Unibeast created USB installer. Erase the EFI partition and macOS partitions. Boot off the Unibeast created installer and install per normal. Now when you reboot after the install, the USB installer will find the SAS attached drive and you can boot into it. Install Multibeast per usual. But once completed, before you reboot, replace the "boot" binary in the EFI partition from the one in the USB stick. You're good to go after that.

FakeSMC is injected properly for me, but anything after that fails (once the SAS driver loads).

Although yours looks more like the Power management kext is failing.

Thanks for this. I'm using Clover with Legacy (BIOS) booting. Do you think that could be contributing?