Implement NVRAM variable reading

[khronokernel]

Currently with kryptonite you support reading the configuration variables from boot-args, one suggestion would be to support reading from both boot-args and dedicated NVRAM entries. Example:

4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 GUID is OpenCore/Lilu's GUID and is commonly used by other community kexts. The idea of reading NVRAM variables directly can be found in RtcMemoryFixup (RTC ranges can be defined either with the boot-arg rtcfx_exclude=xxx or with the stand alone variable rtc-blacklist. Boot-args will take precedence over dedicated args).

The goal of this would be to reduce the clutter in boot-args, however whether you feel this is beneficial is up to you.

Side Notes

1. Fixing Sandy and ivy Bridge Audio support

Noticed in your README the reference to patched DSDT:

DSDT overrides to address error 12 in Bootcamp.

With OpenCore Legacy Patcher, we've actually found a safer solution where we override the BUF0 Object with a combination of SSDT and ACPI patch:

• SSDT-PCI (compiled)
  • Source
• ACPI Patch

Feel free to implement in your own work, it would be quite a bit safer compared to using a patched DSDT which can cause issues with firmware updates

2. Monterey support

Noticed in your source you limit your kext to Big Sur support, are there currently any concerns with Monterey support? Or is this simply validation concerns/kext was in development before Lilu supported Monterey and thus KernelVersion::BigSur was left

[mayankk2308]

@khronokernel thank you for the suggestions. I don't think I have time to work on this project at the moment but I'll keep these in mind.

1. About NVRAM variable reading, it seems convenient if the goal is to integrate alongside other things. My primary intention was for standalone use on native macOS installs, especially initially (and injecting it as needed is simple anyway).
2. I mentioned the DSDT point as the ability to inject DSDT (eGPU.io users have used this historically/we have a compiled repo of DSDTs for Macs) or whatever to resolve Bootcamp issues with eGPUs is a possibility in OpenCore - I'm not doing anything with it myself in this project nor have the requisite knowledge - but thank you for sharing that insight nonetheless.
3. Monterey should work fine but I haven't tested the latest betas to verify this (I only tested beta 1). When written, Monterey wasn't supported in Lilu, as you correctly surmise. I'll update this kext eventually, but I am not planning to test every monthly release of Lilu/OpenCore (again time) so updates here will likely be at much lower cadence.

Monterey support will be added eventually (at worst around or before public release/release candidate). Thank you again, I'll revisit your suggestions in the future.