Native NVRAM Available?

[littlecreature]

Hi all.
Although my Z170X-UD3 with bios F23g does not natively support non-volatile nvram I still do not use EmuVariableUefi-64 and it's associated scripts but rather AptioMemoryFix-64, and that works well indeed. After I studied this thread I got the impression that for some mobo/bios combinations, that do not support non-volatile nvram, there is no alternative other than using EmuVariableUefi-64 with it's scripts. In my case I have been using AptioMemoryFix-64 successfully for quite a while and therefore suggest to try that route first because if it works for you you will get crash reports on the next reboot, after your machine crashed.
Greetings

thanks for the tip. I added AptioMemoryFix-64 and NVRAM appears to be supported as a result on my GA Z370N motherboard

 

[Henties]

+1 For a test I've eliminated all of the new ones and there is no change. I'm sure there is a reason they included by default but I can't find any documentation.

Hi @tonymacx86 this has been bothering me for a while as well until I found a discussion thread on the other side of the universe where I learned, so to speak from the horse's mouth (aka coder's keyboard), which drivers would be required if one were NOT to use "Filevault".
These are:

ApfsDriverLoader-64.efi
AptioMemoryFix-64.efi
DataHubDxe-64.efi
FSInject-64.efi
HFSPlus.efi or VBoxHfs-64.efi - I prefer the first one.

If one therefore NEVER intends to use "Filevault all the other drivers that suddenly also find their way into the Clover/drivers64UEFI folder, can consequently be removed.
I have done this some time ago and have as yet not discovered any problems as a result of that removal.
I think this might also interest @littlecreature and of cause other board members as well.
Presently using Clover 4658, but this minimal list was also working with earlier Clover revisions. I deleted
all the "non paying passengers" from my Clover Clover/drivers64UEFI folder round about two revisions ago.

Greetings

 

[littlecreature]

@Henties
Interesting message. Can you share a list of what drivers you have and confirm that NVRAM is working? I will try to replicate with my Z370N.

 

[Henties]

@Henties
Interesting message. Can you share a list of what drivers you have and confirm that NVRAM is working? I will try to replicate with my Z370N.

Hi @littlecreature the divers I use are listed in my #64 posting of this thread and yes my nvram is working with those drivers although YMMV.
Greetings

 

[harrocan]

Works fine on GA-Z170-D3H with AptioMemoryFix-64.efi and removed EmuVariable64

 

[Namok88]

Same as @harrocan, it also works fine on GA-Z370M-DS3H with AptioMemoryFix-64.efi and removed EmuVariable64

 

[improbable]

Maybe this is the right thread to ask in. I think I have an nvram problem, in which only some setting persist:

sudo nvram nvda_drv=1 <--- this is forgotten, but
sudo nvram test_oct=13 <--- this is remembered, after a reboot

This is using AptioMemoryFix-64.efi, without which neither of these would be remembered.

Apart from which I'm using a pretty minimal EFI folder copied off the USB stick which Unibeast made me. It did have OsxAptioFix2Drv-64.efi but now I deleted that & nothing changed. It does not have EmuVariable64. And this is on HS 10.13.6.

Edit: I learned that RC scripts (installed by multibest I think) are here:
/etc/rc.shutdown.d/80.save_nvram_plist.local
Deleting that file (the only one in folder) seems to change nothing. (I understand from up-thread that this was for use with EmuVariable64, and would write to disk on shutdown... and that AptioMemoryFix-64 is an alternative mechanism allowing physical nvram, which should not require such scripts, and thus should still remember even after a crash / power failure, etc. But I'd love to be corrected if this is wrong.)

Any thoughts on what to try here?

 

[jaymonkey]

sudo nvram nvda_drv=1 <--- this is forgotten, but
sudo nvram test_oct=13 <--- this is remembered, after a reboot

@improbable,

nvda_drv is a MacOS boot argument so is probably a reserved word ... why are you trying to set a nvram variable to that name.
Boot arguments should be defined in Clovers config.plist not in NVRAM

Jay

 

[improbable]

nvda_drv is a MacOS boot argument so is probably a reserved word ...

OK that would explain the weird behaviour! Perhaps I should conclude that Nvram is working & look elsewhere?

I know it's also used as a boot arg... the one and only time I got my computer to talk to its graphics card, writing it to nvram was one of the steps recommended (https://www.tonymacx86.com/threads/...700k-amd-vega-56.239969/page-287#post-1791805) as well as giving it as a boot argument, but I've no idea which mattered... and have not managed a repeat performance.

Edit: Now I'm unsure again. The effect (or at least an effect) of ticking selecting nvidia web drivers in the nvidia driver manager menu, is precisely to write this setting to nvram. So perhaps it ought to persist. Might something else be changing this setting, on shutdown? As mentioned above I deleted the RC script, there is nothing else in /etc/rc.shutdown.d/

$ nvram -p | grep test
test_oct    13
$ nvram -p | grep nv

### click web drivers in menu

$ nvram -p | grep nv
nvda_drv    1

### look for other scripts?

$ cd /etc/rc.shutdown.d/
$ ls rc.*
rc.clover.lib    rc.common    rc.netboot

rc.boot.d:
10.save_and_rotate_boot_log.local        70.disable_sleep_proxy_client.local.disabled
20.mount_ESP.local

rc.shutdown.d:

 

[vulgo]

@improbable,

nvda_drv is a MacOS boot argument so is probably a reserved word ... why are you trying to set a nvram variable to that name.
Boot arguments should be defined in Clovers config.plist not in NVRAM

Jay

The NVIDIA webdriver starts when that NVRAM variable is set. @improbable - Clover will also set/unset that variable if NvidiaWeb setting is present in config.plist. The NvidiaWeb setting is not required when nvram is working aka natively.