Jump to content

EFI Variable Store on Aptio V (Haswell-E and up)


mhaeuser
 Share

198 posts in this topic

Recommended Posts

*sigh* Using that -free2000 driver and wondering why Variable Store access doesn't work... Two options.

1) That driver just wipes anything from the kernel base address till 4GB or 8GB (don't remember). Well, I am pretty sure the Variable SMM Communication Buffer is somewhere in that range and just gets purged away.

2) If the range is not purged away, it could be that Aptio V changed from using RT_data for SMM communication (Aptio IV way) to using Reserved (EDK2) way. AptioFix mods the memory map for Reserved regions not to be mapped during RT, which would mean the buffer cannot be used by UEFI.

 

for 1), you cannot do anything, that's just how it is then.

for 2) you could disable the Reserved convesion code (Lib.c "if ((Desc->Attribute & EFI_MEMORY_RUNTIME) != 0 && Desc->Type == EfiReservedMemoryType)"). If this doesn't work, you can also remove the code that follows ("if ((Desc->PhysicalStart < 0xa0000) && (PhysicalEnd >= 0x9e000))"). Obviously don't remove just that, but the entire block.

 

EDIT: Is -Free2000 OSS even?

EDIT2: EDK2 does NOT use Reserved either, remembered it incorrectly.

Link to comment
Share on other sites

My experience is that my system is more stable with OSXAptioFix2Drv-free2000.efi than with OSXAptioFix2Drv.efi.

In fact, according to the available doc, OSXAptioFix2Drv-free2000.efi should not differ from OSXAptioFixDrv.efi. The change is described in this ticket, but this has already been merged by rehabman in OSXAptioFixDrv.c since r3409.

 

Anyway, according to my earlier tests and reports from multiple Skylake users, the NVRAM issue is present even with OSXAptioFix2Drv.efi. So more investigation seems useful.

I switched back to OSXAptioFix2Drv.efi and performed a new series of dumps that I attach here. If you can clarify this NVRAM issue, it would be much appreciated.

 

 

 

 

 

bcfgBootDump.txt

dmem.txt

memmap.txt

dmpstoreAll.txt.zip

DarwinDumper_3.0.2_09.11_19.25.39_iMac14,2_AMI_X64_3899_Sierra_16B2555_barijaon.zip

Link to comment
Share on other sites

In fact, according to the available doc, OSXAptioFix2Drv-free2000.efi should not differ from OSXAptioFixDrv.efi.

 

Nonsense...

 

The change is described in this ticket, but this has already been merged by rehabman in OSXAptioFixDrv.c since r3409.

 

This is unrelated.

 

Anyway, according to my earlier tests and reports from multiple Skylake users, the NVRAM issue is present even with OSXAptioFix2Drv.efi.

 

Anyone (including you, barijaona), who can boot with stock AptioFix2, try this: https://www.dropbox.com/s/zu5jixphkr4elk0/OsxAptioFix2Drv.efi?dl=0

Link to comment
Share on other sites

It did not boot  ^_^

 

[edit]

The macOS reboot seems to occur just after FakeSMC is loaded.

For the record, a Clover log.

Why did you make AppleIntelSKLGraphicsFramebuffer patches if you have no Intel Graphics at all?

Numerous SSDT loaded also will not clear the reason of reboot.

Link to comment
Share on other sites

Why did you make AppleIntelSKLGraphicsFramebuffer patches if you have no Intel Graphics at all?

Numerous SSDT loaded also will not clear the reason of reboot.

I tested first with the IGPU and added the Nvidia card later.

 

Will test removing these in the evening.

 

Aside note : I am pretty sure that OSXAptioFix2Drv.-64 efi worsens the reboot problem. I will probably give the latest version of OSXAptioFixDrv.efi a try.

Link to comment
Share on other sites

I tested first with the IGPU and added the Nvidia card later.

 

Will test removing these in the evening.

 

Aside note : I am pretty sure that OSXAptioFix2Drv.-64 efi worsens the reboot problem. I will probably give the latest version of OSXAptioFixDrv.efi a try.

 

https://www.dropbox.com/s/zu5jixphkr4elk0/OsxAptioFix2Drv.efi?dl=0

Might again not boot. If it boots, might be hibernation does not work.

Link to comment
Share on other sites

https://www.dropbox.com/s/zu5jixphkr4elk0/OsxAptioFix2Drv.efi?dl=0

Might again not boot. If it boots, might be hibernation does not work.

 

Does not boot.

 

Why did you make AppleIntelSKLGraphicsFramebuffer patches if you have no Intel Graphics at all?

Numerous SSDT loaded also will not clear the reason of reboot.

 

 

I removed the patches and attach here the dumps for reference.

memmap.txt

dmpstoreAll.txt.zip

DarwinDumper_3.0.2_11.11_06.09.59_iMac14,2_AMI_X64_3899_Sierra_16B2555_barijaon.zip

Link to comment
Share on other sites

I have a motherboard on Z97 - ASUS Maximus VII Impact, who also suffers from a lack of write access to the NVRAM.

 

I would like to help and make a dumps, but I'm doing something wrong and I can not do the dumps in the Clover EFI Shell. Can someone instruct me how to make them?

Link to comment
Share on other sites

I removed the patches and attach here the dumps for reference.

 

No need for dumps if you cannot boot OS X. :P

This is the last idea I have without actually reversing the code: https://www.dropbox.com/s/zu5jixphkr4elk0/OsxAptioFix2Drv.efi?dl=0

This should actually boot again... idk if it will work.

 

 

I can not do the dumps in the Clover EFI Shell

 

A slightly little bit vague...

Link to comment
Share on other sites

No need for dumps if you cannot boot OS X. :P

This is the last idea I have without actually reversing the code: https://www.dropbox.com/s/zu5jixphkr4elk0/OsxAptioFix2Drv.efi?dl=0

This should actually boot again... idk if it will work.

 

 

In this buld I can boot to Yosemite, but nvram not works. Previus buids macOS not working at all - hangup or reboot on boot. 

 

 

A slightly little bit vague...

 

forget - my mistake...

 

here is dumps from my motherboard: ASUS Maximus VII Impact (Z97 + i7-4790K) BIOS 3003, dumps from clover 3922

Maximus VII Impact Bios 3003 Clover 3922.zip

Link to comment
Share on other sites

No need for dumps if you cannot boot OS X. :P

Clarification if needed : I was referring to slice's remark that some patches might muddy the waters regarding diagnostics of the situation. But of course, these dumps were done using the stock OsxAptioFix2Drv-64.efi, while your version is named OsxAptioFix2Drv.efi

 

 

This is the last idea I have without actually reversing the code: https://www.dropbox.com/s/zu5jixphkr4elk0/OsxAptioFix2Drv.efi?dl=0

This should actually boot again... idk if it will work.

It boots, but does not preserve NVRAM. Here are the dumps.

 

Question : is it normal that DarwinDumper retrieves (correctly) csr-active-config as 67 00 00 00 , while `nvram -p` still gets 00 00 00 00 ? Of course, I have removed EmuVariableUefi-64.efi and nvram.plist.

iMac:~ barijaon$ nvram -p
fmm-computer-name	iMac
bootercfg	%08%00
bluetoothInternalControllerInfo	%90%82%ac%05%00%00%80%14%a4^`%dc%e5%d2
nvda_drv	1%00
security-mode	none
SystemAudioVolumeDB	%f0
flagstate	%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
bluetoothActiveControllerInfo	%90%82%ac%05%00%00%00%00%80%14%a4^`%dc%e5%d2
EFILoginHiDPI	%00%00%00%00
csr-active-config	g%00%00%00
SystemAudioVolume	A
EFIBluetoothDelay	%b8%0b
LocationServicesEnabled	%01
iMac:~ barijaon$ 

memmap.txt

dmpstoreAll.txt.zip

DarwinDumper_3.0.2_12.11_02.52.48_iMac14,2_AMI_X64_3899_Sierra_16B2555_barijaon.zip

Link to comment
Share on other sites

 Share

×
×
  • Create New...