@FriFlo @MuffinCrumbs @totototo @digumo
These are all good arguments and I think we are all in agreement on the essential points.
- We should use an alternative memory driver if it works. The Build Guide will continue to recommend OsxAptioFix2Drv-free2000 for the time being because it allows everyone to come on board with a working system. Later they can and should switch to something else if it works.
- If I remove my WiFi/BT card, I can use AptioMemoryFix. If others disable their iGPU, they can use AptioMemoryFix. So this type of tradeoff should also be considered. If you're okay without iGPU (e.g. SMBIOS iMacPro1,1) then this is a valid tradeoff.
- As development of OpenCore and FwFirmwareServices proceeds, we may have a truly viable alternative to both AptioMemoryFix and OsxAptioFix2Drv-free2000. Thanks to @MuffinCrumbs and @rj510 for raising awareness of this coming alternative to Clover.
- My experiments with alpha builds of OpenCore, unfortunately, ended in boot failures 100% of the time (specifically, errors involving some missing biometric device). Will try again as OC matures; I understand it's at public beta stage now.
A couple more comments and I'll leave it at that...
- @MuffinCrumbs is right, "that people would defend their use of things. Defend how they use the driver." I use the driver because I have no alternative and because there have not been any ill effects so far. This does not ensure long-term safety by any means. Even a future bug in AptioMemoryFix or FwFirmwareServices could brick your system. FwFirmwareServices have just entered Beta, so you're putting yourself at extra risk.
- Regular full backups are the single most effective guarantor of our long-term computational well-being. Nothing else comes close.
- Memory modules can fail (and they have).
- CPUs can burn out from overheating and overclocking.
- Motherboards can get bricked from a firmware update gone wrong.
- Power surges and spikes can burn out power supplies.
- An EFI memory driver can brick the motherboard.
- Even a bug in a "safe" memory driver can brick the motherboard.
- All of these are valid risks. We face these risks every day. And the "protection" we use is Carbon Copy Cloner -- to use @digumo's analogy of an STD.
Without much clue about hardware or software, this makes a lot of sense to me. Hey, this is a hackintosh - it is not a supported system anyway, so, everybody has to know, there is a risk that hardware goes wrong with any supported system and with a hack, there always might be additional risk! If you mind that, go and buy a $6000+ mac pro!
We can build 3-4 Designare builds (at higher specs) even for that base price and there isn't a chance that base mac pro will outperform these.
In case I need GPU support, can't update to Catalina or buy the FENVI card or something doesn't work anymore for whatever reason, I will return to free2000 without a doubt!
I must say, I like how we can discuss things here with a cordial manner. There are many places you can't have that.
I won't really comment on much. I'm sure I could say a lot though.
FwRuntimeServices.efi is actually almost the same as AptioMemoryFix, just highly "modular" and regulated. There will most likely be more added to the booter configuration, eventually. This said, under no circumstances does it overwrite memory, regardless of not finding proper allocation. Following the history of AptioMemoryFix, it was one of the solutions to not use any methods overwriting the memory. However, It is correct to say that a hackintosh is perhaps not as stable as MacOS, and therefore, one would back it up. This is highly recommended, regardless of any solutions used.
Sure, a hackintosh isn't a real Mac. But you want it to run as smooth as possible. i.e. you choose the right SMBIOS profile for several reasons, one being PowerManagement. If you have an i9 9900 or i7 9700, you'd most likely not go for iMac 15,1 SMBIOS profile, another reason could be to have proper AGDP signalling.
I would argue, it's all about
knowing the risk. I'm not happy about using
OsxAptioFix2Drv-free2000 however for right now it allows me to enable
Sidecar and this functionality I need for testing my iOS builds. I think Using something and Knowing the risks can be responsible if you're educated and go in to the proposition with your eyes open. If CaseySJ's board bricks he's not going to go run back to the community crying and complaining, he's going to say "darn the bullet caught up to me" and then he's going to shell out for a new board. That is an educated risk. Others who come in to this sport need to be aware as well, but as CaseySJ points out we have many many assassins waiting in the shadows to do in our precious machines. We fight to stay in front of them and for some we are lucky enough to keep a good distance (
my Catalina upgrade went completely smooth, knock on wood), others face the dragon and decide to retreat and fight another day (
@rondark). It's always a crapshoot, but I feel there is a higher level of demonization going on here for CaseySJ's choice of promoting the use of this driver. It's less of a choice than it is a lack of options. His build (and same as mine) does not lend it self to running any other memory driver at this time. I am, and will, totally take up the challenge to find an alternative (
your suggestion of trying other slide= choices and or decoding the memory map to see if the proper slide= can be calculated). I need to educate myself first, I'm a network cloud architect not a hardware engineer so I have some studying to do.
I guess in the end I would say we are all responsible people and responsible for our own choices. Go in to this hobby with your eyes open to the wonders and splendor but also the risks, work, and sometimes frustration that it can bring. Nothing is free.....
Fair point. This is why I'd suggest to perhaps set a disclaimer for the use of AptioFix2Drv-Free2000. Unless it has already been done so.
Do you have any pointers on the net where I can learn about this process? I've performed some searches but they have been fruitless. Thank you for any direction you can provide..
Well, here is a little guide:
Get the error and note it down, note down the pages of the allocation problem.
Go into Clover > EFI Shell > memmap
You will get an output with the listings of "Type" "START" "END" "# Pages" "Attribution".
lets take the unrealistic error of 0x1A (your noted up error might be different, this is just an example).
Now that you've found the available larger "# Pages", check its "START" value, for the same type: "available".
In this picture, you can probably see that we've found available "# pages" above the site of 0x1A. This would be 0x1E.
Now following this through, we've found the "START" value, being 0x18A4000.
Now that we got a "START" value, note it down.
In most cases, the kernel is allocated at 100000 with the included slide address (slide value *200000)
So let's start with the calculation (0x18A4000-0x100000)/0x200000 = 0xB
Since this is in Base-16, you'd have to convert it to decimals. 0xB = 11.
In this case, slide=11
You can use the calculator inbuilt with Hackintool or the Calculator in MacOS with Programmer settings.
This is based from what Vit9696 posted in the AptioMemoryFix thread, from the link CaseySJ posted.
Vit9696 also describes it in a different thorough way. I suggest that one reads his posts regarding this.
**I must apologise, I am not as good as CaseySJ at making any guides or descriptions. I am fully blind, and I use screenreader and braille display. My 11 year-old nephew helped me with the picture by labelling everything. The picture is taken from the Intel EFI Specification sheet.**
