Jump to content



Member Since 08 Oct 2011
Offline Last Active Private

Posts I've Made

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

03 December 2016 - 05:38 PM

1) MMIO is not reallocated.

2) Nothing RT_* or MMIO is purged... that kinda defeats the purpose.

3) Marking RT_data as MMIO IS preventing relocation.

4) Marking RT_data as MMIO without relocation is what is happening right now.

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

01 December 2016 - 10:56 AM

Why i'm asking - after macos boot i can see that at least one RT_Data and one ACPI_NVS are remapped into upper memory (0xffffff***) and their phys addr <> virt addr. Also, all MMIO has phys addr <> virt addr (and as i can see clover aptio fix is marking some rt_data as mmio). So i'm wondering if that can't be reason of non working nvram

This is mine memory map https://paste.ee/p/NzRWi


No, that is to FIX NVRAM access. RT_data gets relocated by boot.efi and thus the SMM-side of the driver doesn't write to the CommBuffer. MMIO pages do not get relocated. Only one RT_data page remains RT_data, and that's the SystemTable, as it needs to be relocated for the kernel not to crash.

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

30 November 2016 - 08:20 PM

How are you detecting which portion of memory in memmap is used for SMM? I'm trying to understand how things are working, maybe there can be some help from me :) Bcz my nvram is also not working


You can't, but it is known that it's RT_data. I was basically just verifying that AptioFix applied its fixed properly (i.e. RT_code -> MMIO).

DXE and SMM share a buffer to communicate with, while DXE needs to access it virtually (called by macOS) and SMM physically (triggered via an SMI by the DXE drv).

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

27 November 2016 - 02:46 PM

You mean problem is inside of kernel? Yeah, don't like using Hopper too much...

Why would it be a problem in OS X? It's an UEFI problem ofc...

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

27 November 2016 - 01:00 PM

A few days ago, you had suspicions on what might be the reasons. Would you mind sharing them ?


My best guess was that the SMM portion of the driver would be calling ConvertPointer() on the CommBuffer - as SMM runs in physical mode though, that would break things if physical != virtual. As far as I know, physical = virtual on Windows and Linux, at least also (one physical address can have multiple virtual ones), which would have explained why it worked there (does it even?). But I didn't find anything the the driver that hints at that yet.


Can be very useful list of places in clover to investigate (at least approximately, i'm good on gathering code :) )


Nothing in Clover can help you and the code you would be looking for is not open.

© 2016 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy