Contribute
Register

<< Solved >> NVRAM Motherboards z390

Status
Not open for further replies.
I have NVRAM native from bios 0905

you dont have native nvram ...I buy today same mainboard, update bios to 1005 and NO NATIVE NVRAM... :((((((((
check if you have emulate and script installed ...

I'm NOT confirm native nvram under z390 mainboard ... I try many,many mainboard ...MSI, ASUS, GIGABYTE ...none have native nvram ... with any bios version ...


today you made me a loss of 400 euros ... and if I did not ask you twice ...



i have now 7 ( seven) z390 mainboard and none to use me
 
Last edited:
Only AptioMemoryFix-64.efi, necessary now!!!

AptioMemoryFix-64 includes NVRAM fixes.
If OsxAptioFix2Drv-free2000 is used instead then there is no added support for NVRAM.
Many people with Z390 boards have used OsxAptioFix2Drv-free2000 and then added EmuVariableUefi-64 to help with other Z390 related problems which has the spinoff effect of adding NVRAM support.

If OsxAptioFix2Drv-free2000 is used alone then NVRAM support is confined to the BIOS/UEFI.
If the motherboard lacks native NVRAM support then OsxAptioFix2Drv-free2000 alone will have no effect on it.
 
Last edited:
AptioMemoryFix-64 includes NVRAM fixes.
If OsxAptioFix2Drv-free2000 is used instead then there is no added support for NVRAM.
Many people with Z390 boards have used OsxAptioFix2Drv-free2000 and then added EmuVariableUefi-64 to help with other Z390 related problems which has the spinoff effect of adding NVRAM support.

If OsxAptioFix2Drv-free2000 is used alone then NVRAM support is confined to the BIOS/UEFI.
If the motherboard lacks native NVRAM support then OsxAptioFix2Drv-free2000 alone will have no effect on it.

I test what you say... only OsxAptioFix2Drv-free2000 boot but no nvram and lost usb controler... use z370 mainboard who have navite nvram...or I'm wrong ?
 
I test what you say... only OsxAptioFix2Drv-free2000 boot but no nvram and lost usb controler... use z370 mainboard who have navite nvram...or I'm wrong ?

If you use OsxAptioFix2Drv-free2000.efi, you also need EmuVariableUefi-64.efi for emulated NVRAM.

AptioMemoryFix-64.efi and OsxAptioFix3Drv.efi has native NVRAM support but may not work well with Z390.
 
If you use OsxAptioFix2Drv-free2000.efi, you also need EmuVariableUefi-64.efi for emulated NVRAM.

AptioMemoryFix-64.efi and OsxAptioFix3Drv.efi has native NVRAM support but may not work well with Z390.

"AND" or "OR" ????... z390 work with AptioMemoryFix-64.efi but no nvram and not shutdown ...
 
I test what you say... only OsxAptioFix2Drv-free2000 boot but no nvram and lost usb controler... use z370 mainboard who have navite nvram...or I'm wrong ?
It is not a simple problem.
For instance, my TS140 build had native NVRAM support but following a BIOS upgrade then that was no longer the case and I had to emulate NVRAM support.
A future BIOS upgrade restored NVRAM support and emulation was no longer necessary.

In short what works today may not be the case tomorrow and vice versa.
I don't personally know of any 100/200/300 series boards that have native NVRAM support but that does not mean that they do not exist, or that future BIOS upgrades will not affect the current situation.
 
To be honest I'm struggling to navigate this NVRAM issue. I followed @CaseySJ instructions to a "t" and they were as follows:

During the build process a large number of "Couldn't allocate runtime area" or "Error allocating 0x11c45 pages at 0x000000000f302000 alloc type 2" were encountered. These problems were quite persistent, but were finally solved by using OsxAptioFix2Drv-free2000.efi in combination with slide=0. All other memory fix drivers are ineffective on this motherboard. The osxAptioFix2Drv-free2000 driver is included and applied in post-installation, but may also be applied when configuring the USB EFI partition immediately after running UniBeast.

Then further down in one of the spoilers titled: Final Steps in Post-Installation you're presented with the following:
EmuVariable is needed in order to activate Messages, FaceTime, Handoff, and Continuity. Once activated, EmuVariable is not strictly needed, but after every macOS update it will be necessary to install EmuVariable in order to reactivate Messages, FaceTime, etc. For this reason EmuVariable should remain installed at all times (this is a change from the previous version of this Guide, which recommended that EmuVariable be deleted after post-installation).

In my case, I had trouble installing a device driver specific to my Audio Interface as detailed in this post, so as a remedy I tried to use a number of different memory solutions. The only one that worked for me was AptioMemoryFix-64.efi as well as switching from FakeSMC to VirtualSMC per @ModMike post here.

Having made the two changes above I was able to get the machine to boot with VT-d enabled, dart=0 removed and not drop DMAR tables and get all of the important drivers installed and running.

Back to this NVRAM issue. I guess the newb in me is still confused about WHAT NVRAM is and why it's preferred over Emulated VRAM. Also, testing methods depicted on this site are confusing (at least to me) because they never talk about importance of removing Emulated ram and RC Scripts BEFORE running those tests. I read on InsanelyMac, here and other sites where a bunch of people think they have NVRAM because test results simply came back positive.
 
I guess the newb in me is still confused about WHAT NVRAM is
Non Volatile Random Access Memory is memory that stores values that survive between OS boots and when the computer is powered off in a similar way to the CMOS settings for the BIOS/UEFI.

why it's preferred over Emulated VRAM
Native NVRAM is preferred because it is easier and more like a real Mac.
Emulated NVRAM is only required when native NVRAM is not available.

I read on InsanelyMac, here and other sites where a bunch of people think they have NVRAM because test results simply came back positive.

That is precisely the confusion that lead @DexterOX to state that he had native NVRAM support when he was in fact emulating it which in turn caused @corint1 to needlessly waste another 400€.
 
To be honest I'm struggling to navigate this NVRAM issue. I followed @CaseySJ instructions to a "t" and they were as follows:



Then further down in one of the spoilers titled: Final Steps in Post-Installation you're presented with the following:


In my case, I had trouble installing a device driver specific to my Audio Interface as detailed in this post, so as a remedy I tried to use a number of different memory solutions. The only one that worked for me was AptioMemoryFix-64.efi as well as switching from FakeSMC to VirtualSMC per @ModMike post here.

Having made the two changes above I was able to get the machine to boot with VT-d enabled, dart=0 removed and not drop DMAR tables and get all of the important drivers installed and running.

Back to this NVRAM issue. I guess the newb in me is still confused about WHAT NVRAM is and why it's preferred over Emulated VRAM. Also, testing methods depicted on this site are confusing (at least to me) because they never talk about importance of removing Emulated ram and RC Scripts BEFORE running those tests. I read on InsanelyMac, here and other sites where a bunch of people think they have NVRAM because test results simply came back positive.

On real Mac, there is information that's stored in NVRAM. You can see what's stored there by entering the following in to Terminal:
Code:
nvram -p

As you can see there's all sorts of stuff there that the system requires to function correctly.

In my opinion, the biggest disadvantage to using emulated NVRAM is that you will not get kernel panic reports if/when you get a kernel panic and restart the system. This works when you have native NVRAM. This can be an invaluable time saver when trying to troubleshoot a problem.

When I tested my Gigabyte Z390 motherboard a few weeks ago, I did NOT have native NVRAM working. The only way I could get macOS to work correctly was with the use of EmuVariableUEFI-64.efi (aka emulated NVRAM). I did not try VirtualSMC. I did try all the Aptio fixes that I am aware of.

On my old Z170 (I no longer own this) and my current Z370 motherboard, native NVRAM worked with AptioMemoryFix-64.efi and OsxAptioFix3Drv.efi.
 
On real Mac, there is information that's stored in NVRAM. You can see what's stored there by entering the following in to Terminal:
Code:
nvram -p

As you can see there's all sorts of stuff there that the system requires to function correctly.
You mean this?:
Code:
iMac-i7-3:~ luckyal$ nvram -p
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>4B03873D-3A57-4B79-A2B6-1439B375614E</string></dict></dict></dict></array>
fmm-computer-name    iMac i7
security-mode    none
SystemAudioVolumeDB    %f0
EFILoginHiDPI    %01%00%00%00
SystemAudioVolume    A
EmuVariableUefiPresent    Yes
efi-boot-device-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%00%1b%01%01%06%00%00%00%03%17%10%00%01%00%00%00dy%a7%1c%93%016F%04%01*%00%02%00%00%00(@%06%00%00%00%00%00`%a2%89%df%00%00%00%00=%87%03KW:yK%a2%b6%149%b3uaN%02%02%04%03$%00%f7%fct%be|%0b%f3I%91G%01%f4%04.hB%18%fe`(%ae%16%f3I%a3%fc%14%05%e6La%9d%7f%ff%04%00
csr-active-config    g%00%00%00
specialbootdevice    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%00%1b%01%01%06%00%00%00%03%17%10%00%01%00%00%00dy%a7%1c%93%016F%04%01*%00%02%00%00%00(@%06%00%00%00%00%00`%a2%89%df%00%00%00%00=%87%03KW:yK%a2%b6%149%b3uaN%02%02%04%03$%00%f7%fct%be|%0b%f3I%91G%01%f4%04.hB%18%fe`(%ae%16%f3I%a3%fc%14%05%e6La%9d%7f%ff%04%00
I'm thinking of removing EmuVariableUefi-64.efi from drivers64UEFI folder, so that I can test things out but I'm afraid to screw things up. I would also have to figure out how to uninstall RC Scripts before I try and run the NVRAM validation test.
 
Status
Not open for further replies.
Back
Top