apple: guard gfx restore reset

[seuros]

Work around Mac OS poisoning the EFI boot display on some Macs .

When Mac OS runs, it injects a 'saved-config' GPU-state property into the 'AAPL,PathProperties0000' device-properties variable.

On the next boot, Apple firmware RESTORES that saved config instead of doing a fresh display init, which leaves the EFI GOP framebuffer unbound from the panel scanout.

RefindPlus then draws into a framebuffer that is not scanned out, producing a black screen.

As the firmware restores this state BEFORE RefindPlus loads, the only portable solution is to delete the poisoned variable and warm reset so the firmware re-initialises the display fresh on the immediate re-boot.

The firmware regenerates a clean 'StartupDisplay'-only variable, so this does not loop (a one-shot guard provides additional protection).

This only happens if user multi boots to MacOS.

A small note: When we delete the saved-config property, a chime is emitted. That harmless, and i didnt not want to play gymnastic by muting/unmutting it.

ping @dakanji .

[dakanji]

Dubious about this one I'm afraid, but will take a closer look later.

There is already functionality to clear some Mac nvRAM vars (currently Bluetooth) via sync_nvram that could be extended instead if going forward.

[seuros]

The hang happens with AMD GPUs and 3K+ display.

The IMACs 4/5Ks all get black screen once booted via the EFI. The documented workaround in forums is to clear the nvram once the system boot.

But this patch delete only the variable that causing the GFX to stay dark.

[dakanji]

Understood the intent. Just that this needs some consideration as it enters to potentially sensitive territory.

The issue with 5k iMacs booted with third party UEFI loaders is known.
Your proposed solution is interesting but first, have the people with this issue tried this suggestion from the RefindPlus issue template?

[seuros]

I did use that workaround. I currently have every apple computer from 2007 to 2020 in the bench.

This proposed solution allows the user to use the same config across any apple computer without any extra config.

My goal is to understand that variable later and leverage that config. But first I want to have it boot the same configuration across different resolution and GPUs.||

PS: once this accepted, or a better solution is provided. |
I will open a PR, to fix a refindplus hang with some nvidea gpu. (currently people use refind)

[dakanji]

Thanks for getting back.

It wasn't clear from your response, but did you mean to say that the suggested config setting change "works"?
This is noting your intention to provide a "better" setup.

[seuros]

The suggested official config 'works' if you have the config prior the poisoning or if you reset the nvram.

It also acted weirdly (glitch artifact) when I swapped the disk to a non apple hardware.

My goal is to have 1 config works across every computer (apple, laptop, desktop, tablets, Chromebooks, etc).

PS: Apple firmware used to work without this quirk, but the pushed an updated that limit 3k resolution at boot time for their AMD GPU. (probably 5K is performance hog while the system is booting).

Downgrading the firmware is possible, but that not user friendly (and will get updated anyway once you start macOS).

[dakanji]

Thanks for the clarification.

Note that having "the one config that rules them all" (so to speak) is not a priority. Instead, the priority is for a default config that works for "standard" setups and for those that have edge needs to modify the config to suit their setups. Having said that, will look further into your proposal and get back presently.

A few things to note is that the variable should be considered as AAPL,PathProperties#### as the numeric digits at the end does go up based on the number of "devices" in play. That is, there isn't always just AAPL,PathProperties0000, but there may also be AAPL,PathProperties0001, AAPL,PathProperties0002 etc.

So, you probably want to handle those as well ... Possibly by iterating until you hit a Not Found status.

However, I need to first decide whether it is a good idea to mess with this variable in the first place.
If we do, it will need to be guarded and OFF by default. That is, users will need to actively enable this.
We can look into the Nvidia item mentioned afterwards.

Will get back. Thanks again!

[seuros]

The saved-config property is written ONLY to AAPL,PathProperties0000 because the discrete AMD GPU is always the first device enumerated.

Higher-numbered slots correspond to other output that don't have this issue and are normally initialized at OS boot time.

That extra defensive code will look like generated code, that never gets executed.

As I said I tested this code in every hardware apple architecture released since 2007 till they stopped in 2020. Apple is not going to release anything that break this code as they are on ARM since 2020.

If you have a better alternative that requires no user quirk mangling, I can test the branch with the hardware.

[dakanji]

Noted. Thanks.

Will consider and get back as stated.

[joevt]

The needle string in the commit should probably be a UTF16 type defined like L"saved-config"

I don't know what the problem is but I do know how to properly get and parse the property and save the property.
google getaaplpathprops.

I believe AAPL,PathProperties0001 is created when AAPL,PathProperties0000 gets too large ( > 768 byte). So really, you should concatenate all of them together before parsing.

There may be more than one saved-config - one per device. The property includes a UEFI device path which gfxutil.sh can parse using gfxutil. Try to match the UEFI device path with a device in the I/O registry. I think gfxutil can dump a mapping for you.

https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff
https://github.com/acidanthera/gfxutil

gfxutil.sh has a couple related utilities:

• getaaplpathprops - get the hex (combines all the AAPL,PathProperties#### data)
• setaaplpathprops - set the hex (will split into multiple AAPL,PathProperties#### if necessary)

An example of how to parse the result:
https://forums.macrumors.com/threads/documentation-on-all-parameters-for-nvram.2239034/post-28518123

getaaplpathprops > /tmp/AAPLPathProperties.bin
gfxutil -v -o xml -i bin /tmp/AAPLPathProperties.bin /tmp/AAPLPathProperties.plist > /tmp/AAPLPathPropertieslog.txt
plutil -p /tmp/AAPLPathProperties.plist

The result will look like this:

{
  "PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)" => {
    "saved-config" => {length = 312, bytes = 0x0f084c04 69090000 07000000 0000000f ... 00000000 00000000 }
  }
}

Some useful gfxutil commands.

• gfxutil --help - get help.
• gfxutil -p - print PCI address and UEFI device path.
• gfxutil -t - print PCI address, I/O registry path, UEFI device path.

[dakanji]

@seuros ... Thank you for the well written and potentially beneficial proposed changes to RefindPlus.
Unfortunately however, the proposal will not be merged at this time.

It is understood that the proposal would help with handling known issues affecting 5K iMacs and similar and that this would be done out of the box as part of a stated aim to allow deploying RefindPlus in a manner that allows using a single configuration across different Macs with otherwise varying configuration requirements.

However, the stated configuration aim is not aligned with the current design goal of prioritising a certain standard setup and requiring users with edge requirements, on both Mac and PC, to configure RefindPlus to meet their requirements. This may change in future, but current remains the design goal.

As you found, there is an existing configuration change users of the units with the target issue can make to fully address the issue and this configuration change only needs to be done once.

Please note that the fact of the existence of such a change is not what precludes adopting the current proposal. Rather, that the proposal is adjudged to come with some undesirable side effects.

• Every Mac would have to go through a warm reset cycle on booting RefindPlus regardless of whether they are affected by the targeted issue or not, given that the PathProperties#### nvRAM variable is a standard one generated and expected to be present.

• Units that do not actually need this fix, many of which have fragile nvRAM hardware, would now have what are essentially unnecessary writes to the nvRAM chip on every boot, and trigger cycles that would further further degrade the nvRAM hardware. You may have noticed that RefindPlus particularly tries to minimise wear and tear on nvRAM chips.

• Some of the wording in our discussion thus far, such as the mention of how the discrete AMD GPU is done first and only to updates PathProperties000, suggests that the background/general focus driving development is primarily, if not solely, on All-in-Ones and Portables. However, RefindPlus is primarily focused on MacPros on the Mac side given that whatever is designed to accommodate these is almost certain to also accommodate a "portable". The reverse is often, if not typically, not the same.

• A MacPro may have more than one "discrete" GPU in place and drive several monitors. It may have ThunderBolt and similar cards installed. All of these would be enumerated early and would almost certainly have resulted in multiple PathProperties#### nvRAM variables by the time RefindPlus is loaded.

There are other considerations that cannot all be listed here but I hope those outlined help shed light on the decision.

Thank you once again and look forward to future contributions from you.

---

As an aside, issues with Nvidia GPUs on EFI 1.x units can typically be overcome by activating the supply_uefi configuration option in concert with ensuring that the disable_reload_gop setting remains inactive. The combination of UEFI 2.x spoofing and GOP OptionROM reload allows activating Nvidia GPUs that require UEFI 2.x and would otherwise fail to activate on such units.

The issue template would be updated to spell this out presently.