Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

It all depends on what you get from Clover -> UEFI Shell -> memmap -b.

In my case this is enough. In other cases it won't be. If I were to add another PCI card this may completely fail for me.

I used slide=0 and that's something I've needed in any case. We have the same board and CPU but you have a different GPU.

You could screenshot memmap -b from the UEFI shell and post it here, though you may just be stuck with free2000.

I had a screen shot of my memmap on this post.
 
Over the weekend I experimented with AptioMemoryFix and various slide values (including no slide parameter at all). What I found was baffling and inscrutable. I took a lot of notes which I can summarize later, but the key observations were as follows:

Setting up the Experiment:
  • My configuration:
    • SMBIOS Macmini8,1
    • IGFX enabled and Platform ID 0x3E980003 (headless).
    • Fenvi FV-T919 in bottom PCIe x1 slot.
    • RX 580 GPU in Slot 1.
  • I created 20 different config.plist files, named config-1.plist through config-20.plist.
    • config-1.plist specified slide=1
    • config-2.plist specified slide=2
    • ...
    • config-20.plist specified slide=20
  • At the Clover Boot Menu we can select the Options option (ha!) and pick from any of the .plist files in the CLOVERfolder.
    • This is very handy because we can quickly cycle between all 20 values of slide without having to go through the whole tedium of booting into macOS, mounting EFI, modifying config.plist, etc.
  • I also tried a random set of much larger values of slide, such as slide=167.
  • I ran memmap several times (with several reboots) to make sure that the map was the same or very nearly the same each time.
  • And sure enough, the memory map was the same after each reboot.
Expectations:
  • Based on the information we have seen from vit9696 and others regarding calculation of slide values, I fully expected each slide value to generate a consistent, repeatable memory address.
  • For example, if I use slide=1, I expected macOS kernel to allocate a block of memory at the same memory address on each and every reboot (as long as memmap was the same, which it was).
  • So I selected config-1.plist and I immediately received a Couldn't allocate runtime area error, along with a memory address and size.
  • So I made a note of the memory address and rebooted/repeated the same experiment with the same slide value.
  • Surprisingly, the memory address changed...
  • Each time I repeated the experiment, I got a different memory address.
  • So I switched to slide=2, then slide=3, then slide=4, and so on. And I repeated the experiment multiple times with each slide value.
Overall Observations:
  • As we increase slide from 1 to 20 and then to 167 we expect the base memory address to increase.
  • But I did not observe any such behavior.
  • When I used slide=167 I found that macOS was attempting to allocate memory in the same region as slide=5 or slide=7.
  • When I used slide=15 I found that macOS was attempting to allocate memory in the same region as slide=1 or slide=167 or slide=12.
  • In other words, the value of slide did not seem to make any difference.
  • After spending a couple of hours on this, I was exhausted and happily went back to OsxAptioFix2Drv-free2000.
If you have also experimented with Slide values, did you observe the same behavior? If not, what did you observe?

Dang! Nice job on being thorough! I'll have to set aside some time to do some testing with multiple configs. Since I've only recently gotten into looking at the memmap, I'm keen to read the help in the shell and see if I can pipe the output to a thumb drive. For reference, this is my setup.

  • My configuration:
    • SMBIOS Macmini19,1
    • IGFX disabled yet Platform ID 0x3E980003 (headless) set in Devices -> Properties.
    • Fenvi FV-T919 in bottom PCIe x1 slot. Not running BT/Wifi
    • Radeon VII GPU in Slot 2 (space issues). With BIOS set as primary output.
 
@zzmadd No, it doesn't work since it's a CNVI-Slot that can only accommodate specific Intel-modules. I recommend Fenvi FV-T919.
I ordered in China a plethora of WiFi cards, I just on hand native M.2 (KEY E) modules with adapters to fit into the slot. I'll have to wait for the parcels from China.

Thanks.
 
I had a screen shot of my memmap on this post.

Is that with iGPU enabled in BIOS or disabled in BIOS? Because you have more pages available in that second Available region than I do with iGPU disabled in BIOS.

For me, having far less pages 0x50F7 (20727) available than you was enough to boot with AptioMemoryFix+slide=0+iGPU Enabled (with DVMT Preallocated=32MB) and no conflicting memory fix drivers. I need to run like that longer to see how it handles, but it was the first time I booted with iGPU and no free2000 driver.
 
@CaseySJ, I was wondering about building a fresh install on my system, using the Upgrade Catalina as a basis.
It's all the file structure I am concerned about though. What are your thoughts?
Hello @MACAK,

I'm not sure I understand the question...
  • You can always install Mojave from scratch on a new disk or an existing disk, login to the Mac App Store, then perform an in-place upgrade to Catalina.
  • My experience with in-place upgrade is posted here.
 
My many attempts to install Catalina all end the same way during the second boot. Does this fragment give any clues?
60B1BC5F-472D-42D7-9199-6EFFD32CAB9D.jpeg
 
Is that with iGPU enabled in BIOS or disabled in BIOS? Because you have more pages available in that second Available region than I do with iGPU disabled in BIOS.

For me, having far less pages 0x50F7 (20727) available than you was enough to boot with AptioMemoryFix+slide=0+iGPU Enabled (with DVMT Preallocated=32MB) and no conflicting memory fix drivers. I need to run like that longer to see how it handles, but it was the first time I booted with iGPU and no free2000 driver.

That was with iGPU enabled - hence the alloc error in the other image. I'm running two 16's for 32GB.
 
My many attempts to install Catalina all end the same way during the second boot. Does this fragment give any clues?View attachment 431018
This is a standard kernel core dump. Alas it's all boilerplate stuff.

When I upgraded my Macmini8,1 system from Mojave to Catalina (or from Catalina 10.15 to Catalina Supplemental Update) I had these reboots:
  • First, we begin the Catalina installer from a fully booted macOS desktop.
    • The installer does some prep work.
    • Then the installer gracefully requests a Reboot.
    • This is Reboot #1.
  • Now at Clover Boot Menu we see a new Boot macOS Install from ...option.
    • We choose this option.
    • A few minutes later the installer's progress bar appears.
    • But before it begins to move, there is a sudden reboot.
    • This is Reboot #2. It is possible that the kernel core dump in your screenshot is coming from this step.
  • Now we're again at the Clover Boot Menu and we still see Boot macOS Install from ...
    • We again choose this option.
    • Now the installer takes its time and finishes the entire update.
    • At the end of this update there can be another reboot -- most likely a graceful one.
    • This is Reboot #3.
  • Now at the Clover Boot Menu the previous "Boot macOS Install" option is gone!
    • So we choose the normal "Boot macOS" option.
    • Some final installation or other prep work may occur, but after this the login prompt will appear.
    • There should not be another reboot.
How does your experience differ from this?
 
Back
Top