As such, some downloaded apps cannot be executed without triggering a warning and users may have to go to the Security & Privacy PrefPane to allow the app to run.

To change his and allow execution of all downloaded apps by default, type the following Terminal command:

sudo spctl  --master-disable

The restriction will then be lifted and all downloaded apps will be allowed to run.

I believe this info was 1st reported by Netkas.

Injecting a laptop built-in screen's EDID information in OS X/macOS is sometimes required when the freshly installed OS does not display the desktop properly on screen due to incorrect detection of the screen's hardware properties/capabilities (frequencies, size, etc.). The following describes one easy way to collect a screen's EDID info through an off-the-shelf Windows app but they're are several other methods too (see this somehow complicated method in this deprecated thread for instance):

I can recommend Monitor Asset Manager. I've used it several times in the past. Very simple to use and works without failure.

You'll get the EDID info at the very bottom of the application's main window where it is displayed as a long string of comma separated hexadecimal values. This is what you need to collect and edit to remove all commas and spaces. You may then inject the resulting raw long string of hexadecimal characters as device property in the iGPU settings of your bootloader's config:

AAPL00,override-no-connect        <EDID's hexadecimal string>        DATA

See the WEG User Manual for reference

Posted October 2, 2021

The Dortania documentation refers to the DVMT pre-allocated memory or "stolen memory" when they mention "memory reserved for the iGPU". Years ago, @Firewolf described in details the relationship between stolen memory and DVMT pre-allocated memory on his blog:

https://www.firewolf.science/2015/04/guide-intel-hd-graphics-5500-on-os-x-yosemite-10-10-3/

There's a more recent thread from him here:

https://www.insanelymac.com/forum/topic/345377-surface-pro-patch-the-framebuffer-properly-to-get-rid-of-the-dvmt-assertion-patch/

It can be difficult to understand and differentiate DVMT pre-allocated memory, stolen memory, framebuffer memory, cursor memory, framebuffer size, cursor bytes, etc. And all of these have got nothing to do with VRAM of course... Some of us are familiar with the information provided by @Pike R Alpha many moons ago, the WhateverGreen User Manual or the Hackintool app though none of those clearly define what the various memory instances are. Several years ago, @Rehabman also attempted to explain this and his writings somehow collided with most people's comprehension of things. For instance, when @Pike, WhateverGreen or Hackintool refer to stolenmem and fbmem, @Rehabman spoke of framebuffer memory size and cursor bytes. In the case of the Haswell Azul framebuffer layouts, @Rehabman also spoke of the DVMT pre-alloc requirements when the others speak of stolenmem. Inevitably, this can lead to confusion...

Definitions:

See wikipedia and Google searches.

• VRAM = Video RAM. Common definition is that it stores the pixels and other graphics data rendered on a computer screen.
• DVMT = Dynamic Video Memory Technology. A technology used by Intel to dynamically allocate system memory to use as video memory to handle graphics. DVMT pre-allocated memory is the minimum amount, in multiples of 32MB, that will be allocated to the iGPU for handling graphics. By far and large, manufacturers set this to 32MB by default in BIOS (or certainly used to).
• Framebuffer = a memory buffer held in RAM and containing a bitmap of a video frame, i.e. all the data related to the pixels of an image to be displayed on screen (eg: colours, resolution, etc.).
• Stolen memory = basically, this is the same as the DVMT pre-allocated memory.

As far as Apple's framebuffer drivers/kexts are concerned:

• framebuffer size (aka stolenmem for WhateverGreen*) = the size, in bytes, of a framebuffer layout (it may change according to image characteristics), as defined in the driver/kext.
• cursor bytes (aka fbmem for WhateverGreen*) = the size, in bytes, of a framebuffer layout's overlay used for handling mouse cursor (without modifying the framebuffer's data), as defined in the driver/kext.
• framebuffer VRAM (aka unifiedmem for WhateverGreen) = the max. amount, in bytes, of VRAM allocated by a framebuffer layout, as defined in the driver/kext (since Haswell and Yosemite, this usually is 1536MB).

* As stated above, I believe that Whatevergreen only got it right for Haswell Azul framebuffer layouts with which stolenmem, fbmem and cursormem match their target. Thereafter, I'm of the opinion that WhateverGreen used incorrect names where stolenmem means the actual framebuffer size and fbmem means the actual cursor bytes (size), as stated by @Rehabman.

Mac OS X/OS X/macOS graphics framebuffers:

Let's start by looking at a few examples as illustrated in the WhateverGreen User Manual.

1) Haswell Azul mobile framebuffer 0x0a260006 (used for HD4200/HD4400/HD4600 iGPUs on laptops):

ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F
TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes)
Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
00000800 02000000 30000000
01050900 00040000 87000000
02040900 00040000 87000000

If we look inside the binary code of the Haswell Azul framebuffer kext, we'll find:

0600260A 01030303 00000002 00003001
00006000 00000060 D90A0000 D90A0000
00000000 00000000 00000800 02000000
30000000 01050900 00040000 87000000
02040900 00040000 87000000 FF000000
01000000 40000000 0F000000 01010000
04000000 00000000 0E000000 00000000

which translates to:

0600260A                    -> layout id       (AAPL,ig-platform-id)
01                          -> mobile type     (framebuffer-mobile) 
03                          -> 3 x pipes       (framebuffer-pipecount)
03                          -> 3 x ports       (framebuffer-portcount)
03                          -> 3 x memories    (framebuffer-memorycount)
00000002                    -> 32MB stolen mem (framebuffer-stolenmem)      // Rehabman's DVMT-prealloc requirement
00003001                    -> 19MB FB mem     (framebuffer-fbmem)          // Rehabman's framebuffer size
00006000                    -> 6MB Cursor mem  (framebuffer-cursormem)      // Rehabman's cursor bytes
00000060                    -> 1536MB VRAM     (framebuffer-unifiedmem)
D90A0000                    -> Backlight freq 2777MHz
D90A0000                    -> Max. backlight freq 2777MHz
00000000 00000000
00000800 02000000 30000000  -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 30020000
01050900 00040000 87000000  -> port #2/FB@1: index 01, busid 05, pipe 0900, type 00040000=DP       (framebuffer-con1-type), flags 87000000
02040900 00040000 87000000  -> port #3/FB@2: index 02, busid 04, pipe 0900, type 00040000=DP       (framebuffer-con2-type), flags 87000000
FF000000 01000000 40000000 0F000000
01010000 04000000 00000000 0E000000
00000000

2) Broadwell BDW mobile framebuffer 0x1626006 (used for HD5300/HD5500/HD5600 iGPUs on laptops):

ID: 16260006, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x00000B0B
TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes)
Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS
[1] busId: 0x05, pipe: 11, type: 0x00000400, flags: 0x00000507 - ConnectorDP
[2] busId: 0x04, pipe: 11, type: 0x00000400, flags: 0x00000507 - ConnectorDP
00000800 02000000 30020000
01050B00 00040000 07050000
02040B00 00040000 07050000

If we look inside the binary code of the Broadwell BDW framebuffer kext, we'll find:

06002616 01030303 00002002 00005001
00000060 D90A0000 D90A0000 00000000
00000000 00000000 00000800 02000000
30020000 01050B00 00040000 07050000
02040B00 00040000 07050000 FF000000
01000000 40000000 0B0B0000 01010500
00000000 05000000 00000000 04000000
00000000 00000000 00000000 00000000
00000000 C8000000

which translates to:

06002616                    -> layout id       (AAPL,ig-platform-id)
01                          -> mobile type     (framebuffer-mobile) 
03                          -> 3 x pipes       (framebuffer-pipecount)
03                          -> 3 x ports       (framebuffer-portcount)
03                          -> 3 x memories    (framebuffer-memorycount)
00002002                    -> 34MB stolen mem (framebuffer-stolenmem)     // Rehabman's framebuffer size
00005001                    -> 21MB FB mem     (framebuffer-fbmem)         // Rehabman's cursor bytes
00000060                    -> 1536MB VRAM     (framebuffer-unifiedmem)
D90A0000                    -> Backlight freq 2777MHz
D90A0000                    -> Max. backlight freq 2777MHz
00000000 00000000 00000000
00000800 02000000 30020000  -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 30020000
01050B00 00040000 07050000  -> port #2/FB@1: index 01, busid 05, pipe 0B00, type 00040000=DP       (framebuffer-con1-type), flags 07050000
02040B00 00040000 07050000  -> port #3/FB@2: index 02, busid 04, pipe 0B00, type 00040000=DP       (framebuffer-con2-type), flags 07050000
FF000000 01000000 40000000 0B0B0000
01010500 00000000 05000000 00000000
04000000 00000000 00000000 00000000
00000000 00000000 C8000000

3) Skylake SKL mobile framebuffer 0x19160000 (used for HD520/HD530/HD540 iGPU on laptops):

ID: 19160000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000090F
TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes)
Model name: Intel HD Graphics SKL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00040000 87010000

We can't look at the binary code of the Skylake SKL framebuffer because Apple changed the way things are coded inside but it basically translates as follows:

00001619                    -> layout id       (AAPL,ig-platform-id)
01                          -> mobile type     (framebuffer-mobile) 
03                          -> 3 x pipes       (framebuffer-pipecount)
03                          -> 3 x ports       (framebuffer-portcount)
03                          -> 3 x memories    (framebuffer-memorycount)
00002002                    -> 34MB stolen mem (framebuffer-stolenmem)     // Rehabman's framebuffer size
00005001                    -> 21MB FB mem     (framebuffer-fbmem)         // Rehabman's cursor bytes
00000060                    -> 1536MB VRAM     (framebuffer-unifiedmem)
6C050000                    -> Backlight freq 1388MHz
6C050000                    -> Max. backlight freq 1388MHz

00000800 02000000 98000000  -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 98000000
01050900 00040000 87010000  -> port #2/FB@1: index 01, busid 05, pipe 0900, type 00040000=DP       (framebuffer-con1-type), flags 87010000
02040a00 00040000 87010000  -> port #3/FB@2: index 02, busid 04, pipe 0a00, type 00040000=DP       (framebuffer-con2-type), flags 87010000

With the exception of the Haswell Azul framebuffer, we can see that Broadwell BDW and Skylake SKL framebuffers define framebuffer size (WEG's stolenmem) and cursor bytes (WEG's fbmem) characteristics and no DVMT pre-allocated memory (i.e. proper stolen memory). This extends to Kaby Lake KBL framebuffers and later. In my opinion, it's fair to say that @Rehabman's description and wording are the most appropriate/best ones when the WEG view of things got somehow misled by following through on the Haswell framebuffer decoding. To me, there was some mixup, leading to confusion and the said confusion has remained ever since...

Confusion... why?

Because of several things:

1) the observation that the Haswell Azul framebuffers used on Hacks (0x0D220003 for desktops and 0x0A260006 for laptops) defined:

• a DVMT pre-allocated memory (= Stolen memory) size of 32MB
• a framebuffer size of 19MB
• a cursor bytes of 0MB (desktops) and 6MB (laptops; required to be increased to 9MB to fix a minor graphics glitch on some systems)

2) the observation that the Broadwell BDW framebuffers used on Hacks (0x16220007 for desktops and 0x16160006 for laptops) defined:

• no DVMT pre-allocated memory requirement at all
• framebuffer sizes of 38MB and 34MB respectively
• cursor bytes of 38MB and 21MB respectively

3) the observation that the sum of framebuffer size + cursor bytes must be lower than the size of the DVMT pre-allocated memory, failing which a KP occurs at graphics initialisation during startup/boot.

4) In the case of the Haswell Azul framebuffers:

1. DVMT pre-allocated memory requirement is set at 32MB
2. framebuffer size + cursor bytes = 19+0 | 19+6 (or 19+9) = 19MB | 25MB (or 28MB) which is lower than DVMT pre-allocated memory 32MB

-> All is Ok by default.

5) In the case of the Broadwell BDW framebuffers:

1. framebuffer size + cursor bytes for desktops = 38+38 = 76MB which is greater than the usual/default 32MB DVMT pre-allocated memory of most desktops, unless adjusted in BIOS
2. framebuffer size + cursor bytes for laptops = 34+21 = 55MB which is greater than the usual/default 32MB DVMT pre-allocated memory of most laptops, unless adjusted in BIOS

-> Not Ok by default, Kernel Panic (KP) encountered.

6) And the story is the same with subsequent Skylake, Kaby Lake, etc. framebuffers.

Solution:

2 x solutions were engineered to address the issue of KP at graphics initialisation.

1. increase the DVMT pre-allocated memory set in BIOS. Could be complicated and tricky for PCs that do not offer this in BIOS Setup but made easy with Grub Shell if DVMT pre-allocated memory can be identified in BIOS. This method is usually required to gain 4K output.
2. patch the Broadwell, Skylake, Kaby Lake, etc. framebuffer layouts to reduce framebuffer size and cursor bytes so that the sum of them totals less than the usual default DVMT pre-allocated memory of 32MB. This solution does not usually support 4K output.

Although some people do opt for the 1st solution, most people just adopt the 2nd one.

How were the framebuffer patches derived?

If we look at the framebuffer patches that are commonly and generally used, we can observe that they set:

• WEG's framebuffer-stolenmem property , i.e. framebuffer size to 0x01300000 = 19MB (DATA type set to 00003001)
• WEG's framebuffer-fbmem property, i.e. cursor bytes to 0x00900000 = 9MB (DATA type set to 00009000)

i.e. the values typically used on laptops with Haswell iGPUs, this simply because 19+9=28MB which is < 32MB. This is where it all appears to come from.

Is this correct?

By far and large, it is.

But the need to apply such framebuffer patches depends entirely on the host PC's default DVMT pre-allocated memory. On desktop and laptop PCs where DVMT pre-allocated memory can be adjusted in BIOS setup, the patches are unnecessary as long as the DVMT value that is set exceeds the total of the framebuffer size + cursor bytes of the selected/target graphics framebuffer. Typically, a value of 64MB or 96MB takes care of things perfectly, including 4K. Of course, those PCs manufactured with default DVMT pre-allocated memory set to 64MB or more are unlikely to encounter any issue at all.

The framebuffer patches are also unnecessary if the default DVMT pre-allocated memory is increased either though BIOS binmod (difficult and risky) or through Grub shell mod (easy and quickly reversible). This is well illustrated on @Firewolf's blog, linked above (there are other places too such as @Jake Lo's FAQ item here). To give an example, on some Dell laptops (eg. Broadwell Latitude E7x50 or Skylake Latitude E7x70), DVMT pre-allocated memory can be increased by booting a Grub shell and entering the following command:

setup_var 0x432 0x3

This sets DVMT pre-allocated memory parameter located at offset 0x432 to 96MB (0x1 for 32MB, 0x2 for 64MB, 0x3 for 96MB, etc.), the default setting for the laptop in this example being 32MB. This setting will remain valid/in place until BIOS is reset to default settings. It's required to obtain 4K output out of DP/HDMI. Of course, different computers will have different locations/offsets for DVMT pre-allocated memory.

What should I do then?

As stated above, the framebuffer patches apply to most if not all cases. But not for 4K output. Those who feel adventurous or who are computing-literate may opt for the BIOS adjustment alternative. In all cases, the 1st thing to do is to look at the default framebuffer size and cursor bytes settings of the targeted graphics framebuffer, then decide if the sum of them both fits or not in 32MB or any other value set in BIOS for DVMT pre-allocated memory.

Can I use different values?

Absolutely! As long as the golden rule is respected: framebuffer size + cursor bytes < DVMT pre-alloc mem or, in WEG's conventions, stolenmem + fbmem < DVMT pre-alloc mem.

To give a practical example, I experimented on my Skylake/HD520 Dell Latitude E7270 Hackintosh laptop:

• default DVMT pre-allocated memory value set in BIOS: 32MB
• target SKL framebuffer layout: 0x19160000
• default framebuffer size: 34MB
• default cursor bytes: 21MB
• sum of framebuffer size + cursor bytes: 55MB (i.e. > 32MB)

1. Booting with default DVMT pre-alloc mem + no framebuffer patches -> KP/freeze
2. Booting with default DVMT pre-alloc mem + framebuffer size 20MB + cursor bytes 12MB -> KP
3. Booting with default DVMT pre-alloc mem + framebuffer size 19MB + cursor bytes 9MB -> Ok, full graphics acceleration, no 4K output
4. Booting with default DVMT pre-alloc mem + framebuffer size 20MB + cursor bytes 10MB -> Ok, full graphics acceleration, no 4K output
5. Booting with DVMT pre-alloc mem set to 64MB (Grub shell) + no framebuffer patches -> Ok, full graphics acceleration + 4K output
6. Booting with DVMT pre-alloc mem set to 96MB (Grub shell) + no framebuffer patches -> Ok, full graphics acceleration + 4K output

To repair permissions after any any kext addition, removal or modification in /L/E, type the following Terminal commands:

sudo chmod -Rf 755 /L*/E*
sudo chown -Rf 0:0 /L*/E*
sudo touch -f /L*/E*

`

To rebuild the cache, type the following Terminal commands

sudo kextcache -i /          -> will invoke the required kmutil command
sudo kcditto

For additional information on the commands:

man kmutil
man kcditto

nibble:    4   3   2   1   |   4   3   2   1
bits:      -   -   -   -   |   -   -   -   -
           |   |   |   |       |   |   |   |
           |   |   |   |       |   |   |   |
           |   |   |   |       |   |   |   |
          /    |   |   |       |   |   |    \
Dev. Prot.    /    |   |       |   |    \    Kext Sig.
  NVRAM Prot.     /    |       |    \    FS Prot.
     DTrace Prot.     /         \    Task Prot.
           Apple Int.            Kernel Debug.

Source: csr.h (in bsd/sys folder) of 10.11's published XNU source code at https://opensource.apple.com/

On the basis/assumption that Apple Internal & Device Configuration could be kept disabled by default (bit set to 0), CsrActiveConfig could be set to:

• 0000 0011 in binary, i.e. 0x03 (3 in decimal) to disable kext signing and filesystem protection
• 0110 0011 or 0110 1111 in binary, i.e. 0x63 or 0x6F (103 or 111 in decimal) to disable all protections that mattered

If I booted Enoch in verbose mode with CsrActiveConfig=103 (i.e. 0x63), the displayed info showed:

System Integrity Protection status: enabled (Custom Configuration).

Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

At time of writing, in the days of Clover and Catalina, most people still use CsrActiveConfig 0x63 and that's fine. But there are also more flags to control SIP than there used to be in El Capitan:

• Sierra added a 9th flag for Any Recovery OS
• High Sierra added a 10th flag for Unapproved Kexts
• Mojave added an 11th flag for Executable Policy Override

SIP is therefore arranged as follows:

nibble:              #3        |         #2        |         #1     
nibble bits:   4   3   2   1   |   4   3   2   1   |   4   3   2   1
bits:         12  11  10   9   |   8   7   6   5   |   4   3   2   1
               -   -   -   -       -   -   -   -       -   -   -   -
             N/A   |   |   |       |   |   |   |       |   |   |   |
                   |   |   |       |   |   |   |       |   |   |   |
                   |   |   |       |   |   |   |       |   |   |   |
                   /   |   |       |   |   |   |       |   |   |   |
       Policy Over.    /   |       |   |   |   |       |   |   |   |
              Kext App.    /       |   |   |   |       |   |   |   |
                  Recov. OS        /   |   |   |       |   |   |   \
                     Device Config.    /   |   |       |   |   \    Kext Sig.
                            NVRAM Prot.    /   |       |    \   FS Prot.
                               DTrace Rest.    /       \     Task for PID
                                     Apple Int.         Kernel Debug.

where:

Bit #1 = Allow untrusted kexts

Bit #2 = Allow unrestricted FileSystem

Bit #3 = Allow task for PID

Bit #4 = Allow kernel debugger

Bit #5 = Allow Apple internal

Bit #6 = Allow unrestricted DTrace

Bit #7 = Allow unrestricted NVRAM

Bit #8 = Allow device configuration

Bit #9 = Allow any recovery OS

Bit #10 = Allow unapproved kexts

Bit #11 = Allow executable policy override

Bit #12 = N/A

Source: csr.h (in bsd/sys folder) of Mojave 10.14's published XNU source code at https://opensource.apple.com/

Whilst the original CsrActiveConfig of 0x03 or 0x63 remains valid by far and large to most hackintoshers, some folks may also want to allow unapproved kexts on top of unsigned kexts. Keeping the same flags as for CsrActiveConfig 0x63 alongside, this would lead to a new value of 0010 0110 0011, i.e. 0x263 or 611 in decimal.

/!\ Warning, some files in attachment will show as infected, you'll need to disable your antivirus temporarily

     Use at your own risk!

 
1) Universal BIOS Backup ToolKit 2.0.exe - to backup the BIOS (i.e. DellInc.-A07.rom)
2) UEFITool.exe to find the module labeled SetupPrep (not Setup as per FireWolf’s guide) and extract the PE32 image section (setup.bin)

  Update: 

  For Dell Only: Search with this GUID, right click the GUID found and select extract body. Save it as setup.bin

          899407d7-99fe-43d8-9a21-79ec328cac21

3) Universal IFR Extractor.exe to extract setup.bin to a readable text file
4) Use notepad to search for “DVMT” in the text file

    i.e. for the E7450, 2 were found at 0x432 and 0x433 but only 0x432 needs to be changed to 0x3
5) Format an USB drive to fat32 and create a folder name EFI
6) Download the EFI Shell and extract the Boot folder to EFI folder (EFI/Boot/bootx64.efi)
7) Boot system with the USB and select UEFI Boot
    At the grub prompt, enter these commands, hit enter after command, then exit and reboot
    i.e. setup_var 0x432 0x3

To verify if the value was updated, just enter setup_var 0x432 and hit enter, the value will be listed

More detailed instruction in attachment

/!\ Alternatively, just use Lilu.kext + Whatevergreen without having to mess with the BIOS

https://github.com/vit9696/Lilu/releases

https://github.com/vit9696/Lilu/blob/master/KnownPlugins.md

https://github.com/acidanthera/WhateverGreen/releases

DVMT_Tools.zip

If your hardware is not listed, do try and identify the chip your card or dongle is based on. Note that:

• Cards and dongles manufacturers may provide OS X drivers, please consult their web site before asking.
• Chip manufacturers may provide OS X drivers (eg: Ralink, Realtek), please consult their web site before asking.

Use Google to research for potential support or drivers under OS X.

If you remain without suitable answer, please post a compatibility query in the dedicated forum subsection.

Please note that, for years, Intel wireless cards were not supported at all. However, recent development was done and some Intel cards are now fully supported. See here for details:

• https://openintelwireless.github.io
• https://github.com/OpenIntelWireless

Thanks.

OSXL Crew

After a lot of playing around with ASUS acpi tables I have finally come up with a SSDT that will work nearly on all ASUS laptops (Haswell or above) for reading FAN RPM, CPU TEMP and also Custom Controlling FAN. I do not have hardware below Haswell so can't test.

If someone get's it working using this SSDT on machines prior to haswell. Let me and others know.

Background Info:

The system FAN is generally controlled by the embedded controller (EC) but there are methods in ACPI that can let you read and control your system FAN.

As you might know, ASUS machines are the best for hackintosh as they have the best written ACPI code. Like, if it was HP instead of ASUS you would have to acquire a mutex object. Write a value to the EC and then release the object. But in ASUS machines there is a method that takes arguments and does this job automatically. Still.

There are multiple methods in our DSDT that allow us to read and control system FAN.

For example to read FAN speed, there are two ways. If you observe, the FAN speed is at offset 0x93 of EC (Use RWEverything to find out)

So, when we search for Offset 0x93 in the DSDT we get a result like this:

Offset (0x93), 
TAH0,   16,  // TAH0 stands for FAN1
TAH1,   16,  // TAH1 stands for FAN2 (in case your laptop has 2 fans)
TSTP,   16,  // TSTP stores current fan value in some bytes

Note: Instead of using RWEverything if you have a look at method TACH you can see that it stores the values in TAH0 and TAH1 depending upon the Args supplied. So, searching for TAH0 or TAH1 we can see that they are located at offset 0x93

So, now we can read the value from these registers in some units and then we will have to use some formula to convert that unit to RPM.

In order to find that formula, if you have a look at Method TACH in dsdt, you will see:

Method (TACH, 1, Serialized)
{
    Name (_T_0, Zero)
    If (ECAV ())
    {
        While (One)
        {
            _T_0 = Arg0
            If ((_T_0 == Zero))
            {
                Local0 = TAH0
                Break
            }
            ElseIf ((_T_0 == One))
            {
                Local0 = TAH1
                Break
            }
            Else
            {
                Return (Ones)
            }

            Break
        }

        Local0 *= 0x02
        If ((Local0 != Zero))
        {
            Divide (0x0041CDB4, Local0, Local1, Local0)
            Return (Local0)
        }
        Else
        {
            Return (Ones)
        }
    }
    Else
    {
        Return (Ones)
    }
}

So, we know that we have to store the value from TAH0 or TAH1 (depends on Arg0) and then we have to multiply it by 2 and then we have to divide it by 0x0041CDB4 (4312500) to get the value in RPMs.

Once we know that, we could write a simple ACPI code to return the value in RPMs like:

// GRPM means get RPM
Method (GRPM, 0)
{
	// Store value in Local0
	Local0 = \_SB.PCI0.LPCB.EC0.TAH0

	// If local0 is not equal to 0
	If (Local0 != 0){
		// Multiply by 2
		Local0 = Local0 * 2
		// Divide by 4312500
		Divide (0x0041CDB4, Local0, Local1, Local0)
	}

	// Return the value
	Return (Local0)
}

As you can see this is very expensive method. But what we learned here is, If we execute method TACH with Arg0 as 0 (Zero) it will give us the speed in RPM of FAN 1. Similarly, if we use Arg0 as 1 (One) it will return the value in RPM for FAN 2

My laptop only has one FAN so, I can execute method TACH like,

\SB.PCI0.LPCB.EC0.TACH(0) // Using Arg0 as Zero for FAN 1

And it will give me FANs RPM, so, instead of reading from EC and converting bits to RPM this is more preferable. Also, EC bytes may change while patching DSDT so it is a good idea to use dynamic methods so that a single SSDT could work for all machines. One such example is, If you use ACPIBatteryManager then you will have to convert 16bits registers to 8bits. And then, to use that "reading RPM from EC method you will have to create a new method to combine 2 8 bits registers to 1 16 bit like,

// JEBR = Join 8 bit registers
Method (JEBR, 2)
{
    Return ((Arg0 | (Arg1 << 8))) // Arg0 and Arg1 will be 8Bit register 1 and 2 respectively (AH00, AH01)
}

Now moving to FAN control, If you have a look at method QMOD in DSDT:

Method (QMOD, 1, NotSerialized)
{
    If ((Arg0 == Zero))
    {
        Return (Zero) // If arg0 is Zero. Terminate by returning 0
    }

    If ((Arg0 == One))
    {
        ^^PCI0.LPCB.EC0.ST98 (QFAN) // Hmm, ST98 is somewhat related to FAN control
    }

    If ((Arg0 == 0x02))
    {
        ^^PCI0.LPCB.EC0.ST98 (0xFF) // Okay, ST98 again.. Something is interesting
    }

    Return (One)
}

Now, if you look at ST98 you can see:

Method (ST98, 1, Serialized)
{
    If (ECAV ()) // Checked if EC is available, will you write to it?
    {
        Acquire (MU4T, 0xFFFF) // Oh! So you are acquiring a mutex object
        CMD = 0xFF
        EDA1 = 0x98 
        EDA2 = Arg0 // Oh, so you did write Arg0 in EDA2 (Located in EC01 OperationRegion)
        ECAC ()
        Release (MU4T) // Released it here, you did write something to the EC for sure
        Return (Zero)
    }

    Return (Ones)
}

Now, we can understand that, method QMOD (Quiet Mode?) Takes 1 argument that could be (0, 1 or 2). We can eliminate 0 as when we pass Arg0 as 0 it simply returns. 

Interesting are args 1 and 2

When using 1 it passes Arg0 to ST98 as QFAN's value (Hmm.. What is this QFAN)

When using 2 it passes Arg0 to ST98 as 0xFF (255) (Oh wait! according to ACPI spec, 255 is max allowed FAN value.)

Gotcha! We can use ST98 and pass it an arg ranging between 0x0 (0) to 0xFF (255) where 0 is for FAN off and 255 is for Max allowed or auto.

But, why is there a QMOD method then? There might be some good reason for that. So, we will not invoke ST98 directly but will use the modus operandi of method QMOD

Like, we will first store that max allowed FAN value in QFAN

Then, we will invoke QMOD with Arg0 as 1 (One). Which will invoke ST98 for us hence, setting the max allowed speed for FAN.

So, the ACPI code for this would be:

Method (SETR, 0)
{
    QFAN = 200 // Suppose we want to use max allowed value as 200

    // Now we can call QMOD with Arg0 as 1
    QMOD (1)
}

Now we know what to do. We now just need to write a method that can calculate the CPU temperature and then set FAN RPM accordingly. This is when you will use my SSDT-FAN

How to implement:

Requirements:

• FakeSMC kext along with sensors installed at /L/E or /S/L/E (DO NOT INJECT USING CLOVER)
• ACPIPoller.kext
• HWMonitor for monitoring CPU Temp and FANS
• My SSDT-FAN.aml

Installation:

• Place SSDT-FAN.aml to /EFI/CLOVER/ACPI/patched (If using sorted order make sure you add SSDT-FAN to it)
• Install ACPIPoller to /L/E or /S/L/E (not both and definitely do not inject using CLOVER)

Configuration:

• You can set "Name (UCFC, One)" to "Name (UCFC, Zero)" in my SSDT-FAN in case you want to use default FAN control method as provided by your OEM. My SSDT will only provide FAN RPM reading and CPU Temp reading.

Achievements:

• Default scaling that ASUS provided was from 2200RPM to 2900RPM (Fan spinning fast without use)
• I managed to bring scale it from 255RPM to 5026RPM (Fan turns off if temp
• Temp rarely goes above 53˚C (Went up to 68 earlier)

Technicalities:

As we know know how to implement custom fan control using various methods in our DSDT we can't really use them as is in real life scenarios as FAN will literally be dancing. You might have observed that temperature keeps fluctuating a few degrees every second while you are working on something. Moreover, we need an automated method that can read and set FAN RPM.

So, my SSDT calculates average temperature and then also waits for 2 seconds (to handle fluctuation) before increasing the RPM and waits for 5 seconds (to let CPU cool) before lowering RPM. You can edit this timeout by editing "Name (FCTU, 2)" for FanControlTimeoutUp and "Name (FCTD, 5)" for FanControlTimeoutDown.

Method to calculate average accredited to RehabMan as he wrote the code first. There is only one known way to calculate average in maths. LOL.

If you want to know how it is implemented, read this code:

Note: This code is a part of my single optimizer SSDT project for ASUS laptops (Means, I am working on a single SSDT that you could place in your CLOVER/ACPI/patched and will have everything working without patching DSDT. You can customize SSDT using Device ANKD (A Nick's Device) like you can configure this SSDT to use custom FAN control or not). You can have a look at WIP code here

// SSDT for FAN readings and custom FAN control for ASUS laptops

// Copyright, black.dragon74 <www.osxlatitude.com>

// Please configure the options in Device ANKD before compiling this SSDT

DefinitionBlock("SSDT-FAN", "SSDT", 2, "Nick", "AsusFan", 0)
{
    // Declare externals
    External (\_SB.QFAN, FieldUnitObj)
    External (\_SB.ATKD.QMOD, MethodObj)
    External (\_SB.PCI0.LPCB.EC0.ECAV, MethodObj)
    External (\_SB.PCI0.LPCB.EC0.ECPU, FieldUnitObj)
    External (\_SB.PCI0.LPCB.EC0.ST83, MethodObj)
    External (\_SB.PCI0.LPCB.EC0.ST98, MethodObj)
    External (\_SB.PCI0.LPCB.EC0.TACH, MethodObj)
    
    
    // Create a Nick's device to take care of this SSDT's configurations
    Device (ANKD)
    {
        Name (_HID, "ANKD0000") // Required. DO NOT change
        Name (UCFC, 1) // Set this to 0 if you don't wanna use my custom FAN control
    }

    // Create devices required by FakeSMC_ACPISensors
    Device (SMCD)
    {
        Name (_HID, "FAN0000") // Required, DO NOT change
        
        // Add tachometer
        Name (TACH, Package()
        {
            "System FAN", "FAN0"
        })
        
        // Add CPU heatsink
        Name (TEMP, Package()
        {
            "CPU Heatsink", "TCPU"
        })
        
        // Method to read FAN RPM (tachometer)
        Method (FAN0, 0)
        {
            // Check is EC is ready
            If (\_SB.PCI0.LPCB.EC0.ECAV())
            {
                // Continue
                Local0 = \_SB.PCI0.LPCB.EC0.ST83(0) // Method ST83 acquires mutex and writes value to EC. O stands for FAN 1, Use 1 for FAN 2
                If (Local0 == 255)
                {
                    // If ST83 is 0xFF (Max fan speed) terminate by returning FAN RPM
                    Return (Local0)
                }
                
                // Else, Get RPM and store it in Local0
                Local0 = \_SB.PCI0.LPCB.EC0.TACH(0) // Method TACH in DSDT returns current FAN RPM in 100s, Arg0 as 0 is for FAN 1, for FAN 2, use Arg0 as 1
                    
            }
            Else
            {
                // Terminate, return Zero
                Local0 = 0
            }
            
            // Return 255, 0 or Fan RPM based on conditionals above
            Return (Local0)  
        }
        
        // Method to read CPU temp (CPU Heatsink)
        Method (TCPU, 0)
        {
            // Check if EC is ready
            If (\_SB.PCI0.LPCB.EC0.ECAV())
            {
                // Then
                Local0 = \_SB.PCI0.LPCB.EC0.ECPU // EC Field storing current CPU temp
                Local1 = 60 // From DSDT
                
                If (Local0 < 128)
                {
                    Local1 = Local0
                }
                
            }
            Else
            {
                // Terminate, return Zero
                Local1 = 0
            }
        
            // Return final CPU temp. ACPISensors take care of unit conversion.
            Return (Local1)
        }
        
        // Custom FAN table by black.dragon74 for ASUS laptops based on RehabMan's idea
        // Quietest fan operation yet coolest CPU.
        // Scaling from values as low as 255 RPM to values as high as 5026 RPM (That's great!)
        // Scaling that ASUS provided was from 2200 RPM to 2900 RPM (Duh!)
        
        // Temperatures. 0xFF means if temp is above 52C, let bios take control of things(auto).
        Name(FTA1, Package()
        {
            32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 0xFF,
        })
        
        // Fan speeds. 255(0xFF) is max/auto, 0(0x00) is for fan off
        Name(FTA2, Package()
        {
            0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 160, 185, 205, 225, 245, 250, 255
        })
        
        // Time out values
        Name (FCTU, 2) // RPM Up
        Name (FCTD, 5) // RPM Down

        // Table to keep track of past temperatures (to track average)
        Name (FHST, Buffer() { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) // Size should match the count of above FTA1 and FTA2 package
        Name (FIDX, 0) 	// current index in buffer above
        Name (FNUM, 0) 	// number of entries in above buffer to count in avg
        Name (FSUM, 0) 	// current sum of entries in buffer
        
        // Keeps track of last fan speed set, and counter to set new one
        Name (FLST, 0xFF)	    // last index for fan control
        Name (FCNT, 0)		// count of times it has been "wrong", 0 means no counter

        // Method to control FAN wrt TEMP
        // Name in ACPIPoller.kext's Info.plist should be FCPU with HID FAN0000
        Method (FCPU, 0)
        {
            // If UCFC is set to 0, terminate
            If (\ANKD.UCFC == 0)
            {
                Return (0)
            }
            
            // If EC is not ready, terminate
            If (!\_SB.PCI0.LPCB.EC0.ECAV())
            {
                Return (0)
            }    
                
            Local5 = \_SB.PCI0.LPCB.EC0.ECPU // Current temperature of the CPU Heatsink
            If (Local5 < 128)
            {
                Local0 = Local5 // Store temperature in Local0
            }
            Else
            {
                Local0 = 60 // As per BIOS
            }    

            // calculate average temperature
            Local1 = Local0 + FSUM
            Local2 = FIDX
            Local1 -= DerefOf(FHST[Local2])
            FHST[Local2] = Local0
            FSUM = Local1  // Local1 is new sum
            
            // adjust current index into temperature history table
            Local2++
            if (Local2 >= SizeOf(FHST)) { Local2 = 0 }
            FIDX = Local2
            
            // adjust total items collected in temp table
            Local2 = FNUM
            if (Local2 != SizeOf(FHST))
            {
                Local2++
                FNUM = Local2
            }
            
            // Local1 is new sum, Local2 is number of entries in sum
            Local0 = Local1 / Local2 // Local0 is now average temp

            // table based search (use avg temperature to search)
            if (Local0 > 255) { Local0 = 255 }
            Local2 = Match(FTA1, MGE, Local0, MTR, 0, 0)

            // calculate difference between current and found index
            if (Local2 > FLST)
            {
                Local1 = Local2 - FLST
                Local4 = FCTU
            }
            else
            {
                Local1 = FLST - Local2
                Local4 = FCTD
            }

            // set new fan speed, if necessary
            if (!Local1)
            {
                // no difference, so leave current fan speed and reset count
                FCNT = 0
            }
            else
            {
                // there is a difference, start/continue process of changing fan
                Local3 = FCNT
                FCNT++
                // how long to wait depends on how big the difference
                // 20 secs if diff is 2, 5 secs if diff is 4, etc.
                Local1 = Local4 / Local1
                if (Local3 >= Local1)
                {
                    // timeout expired, so start setting new fan speed
                    FLST = Local2
                    
                    // Method 1 (Recommended)
                    
                    // Store custom fan value from table in Local5
                    Local5 = DerefOf(FTA2[Local2])
                    
                    // Set QFAN value to that of Local5
                    \_SB.QFAN = Local5
                    
                    // Execute QMOD with Arg0 as 1(One) to set FAN's max allowed speed to that of \_SB.QFAN
                    \_SB.ATKD.QMOD(1)
                    
                    // End Method 1
                    
                    // Method 2 (Works but not recommended) Uncomment the line below to use this (remember to comment lines in method 1)
                    
                    // \_SB.PCI0.LPCB.EC0.ST98 (DerefOf(FTA2[Local2]))
                    
                    // End Method 2
                    
                    // Reset FAN count (Required in either methods)
                    FCNT = 0
                }
            }
            
            Return (1) // Return something as this is a requirement of a ACPI Method
        }                    
    }
}    

Moment of joy:

Problem Reporting:

Attach proper problem reporting files. See How to generate proper problem reporting files

Note: If you see FAN RPM = 255 and hear a lot of noise from FAN it means your FAN is running at it's maximum speed.

Regards

ACPIPoller.zip

SSDT-FAN.zip

To repair permissions, type the following Terminal commands:

sudo chmod -Rf 755 /S*/L*/E*
sudo chmod -Rf 755 /L*/E*
sudo chown -Rf 0:0 /S*/L*/E*
sudo chown -Rf 0:0 /L*/E*

`

To rebuild kextcache and prelinked kernel, type the following Terminal command:

sudo touch -f /S*/L*/E*
sudo touch -f /L*/E*
sudo kextcache -Boot -U /

`

Sometimes, the system returns an error message about not being able to modify/rebuild the cache and/or the prelinked kernel. In this case, the existing cache and prelinked kernel can be deleted using the following Terminal commands:

sudo rm -Rf /S*/L*/PrelinkedKernels
sudo rm -Rf /S*/L*/Caches/com.apple.kext.caches

The cache and prelinked kernel can then be rebuilt using the above touch and kextcache commands.

Thankfully, there are tools that can be used from Windows to obtain the desired Graal!

We can recommend the 2 x following tools:

1) TransMac

https://www.acutesystems.com/scrtm.htm

2) Boot Disk Utility

http://cvad-mac.narod.ru/index/bootdiskutility_exe/0-5

See this thread also: https://osxlatitude.com/forums/topic/10494-how-to-create-mac-installation-usb-from-windows

Those who know how to use Google may look up for tutos. Example:

https://www.wikigain.com/create-macos-high-sierra-bootable-usb-installer-windows-10/

1) LAN/Ethernet interface

A LAN/Ethernet interface be present and configured as 1st interface en0. This is mandatory for all of the above apps. Status can be assessed by checking the MAC address associated with each listed interface returned by Terminal command:

ifcconfig

For instance:

admin@d630n ~ % ifconfig
[...]
[...]
[...]
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500     --> *** en0 ***
options=403<RXCSUM,TXCSUM,CHANNEL_IO>
ether 00:2X:XX:XX:XX:19                                --> *** This is the MAC address ***
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (<unknown type>)
status: inactive

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500     --> *** en1 ***
options=400<CHANNEL_IO>
ether 00:2X:XX:XX:XX:70                                --> *** This is the MAC address ***
inet6 fe80::1cb6:fa47:fd8a:c1eb%en1 prefixlen 64 secured scopeid 0xc 
inet 192.168.1.117 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
[...]
[...]
[...]

The LAN/Ethernet interface MAC address can be verified in the Hardware tab of the Ethernet interface listed in the Network PrefPane:

If your LAN/Ethernet interface is unsupported or if your computer does not have one (it happens), use Rehabman's NullEthernet kext to fake one: RehabMan-NullEthernet-2016-1220.zip

If your LAN/Ethernet interface is not 1st interface en0:

• remove all interfaces from your Network PrefPane
• delete NetworkInterfaces.plist from /Library/Preferences/SystemConfiguration folder
• reboot

The LAN/Ethernet interface should then return as 1st interface en0; if no interface is present in your Network PrefPane after reboot, add them manually, starting with Ethernet.

2) Serial number, MLB, ROM

These pieces of information are mandatory for Messages and without them, the app just won't work. These values can be set in Clover config through Clover Configurator app. Open your Clover config in CC and proceed as follows:

• SMBIOS tab:

* If not done already (but it should), click on the selection list button and pick the Mac model that best fits your Hackintosh computer hardware

* Click on each Generate New button a few random times to generate a new Serial Number and a new SmUUID number

• System Parameters tab:

* Click on Generate New button a few random times to generate a new Custom UUID number

• Rt Variables tab:

* Make sure the from SMBIOS case in the top left corner is selected/checked

* Click on the down arrow of the ROM field, select UseMacAddr0 then click on Generate New button a few random times. This will generate a new ROM value

* In the black section in the middle, select the MLB value displayed and copy/paste it in the MLB field above

Save your Clover config and reboot. Your Hackintosh is now set to use AppStore, FaceTime, iCloud and Messages.

Suggestions/Discussions: HERE

Hello guys,
I have seen many instances where people start a thread with the problem they are facing on their hack.

They try to describe the issue in their own way that most of the times, is not able to properly describe what's going wrong with their system.

The developers and other advanced members on OSXL can point out the problem exactly when they have a set of files, called problem reporting files.

These are basically a set of files that contain various logs and some other components.

Many a times a normal user can not generate those files properly and it leads to a lot of wastage of good time, frustrated by this, I wrote a script to generate proper problem reporting files. You can have a look at the source code here

The purpose of this guide is to tell the normal user on how to generate those files properly for debugging.

I wrote a script that automatically installs that debug report generator script and then gives you a .zip output.

If you are seeking help about a problem and you must attach problem reporting files as it saves a lot of time.

How to generate debug report:-

It is very simple, you just have to download the attached script and run it. The script in attachment will install the tool for you and will then prompt if you want to generate the files.

If you want to generate files next time, you just have to invoke: "gen_debug" from terminal (without quotes)

How to download and run attached script :-

• Unzip the downloaded zip file
• Open terminal
• Assuming your script is in Downloads folder, type the following code :-

chmod a+x ~/Downloads/install_tools.sh
~/Downloads/install_tools.sh

Args for gen_debug:

You can use custom set of args for controlling gen_debug output, this list will be updated as new features become available

• gen_debug -u || To update your copy (available from ver2.1+)
• gen_debug -sysprofile || To include your system profile in the dump (available from ver2.2+)
• gen_debug -sysprofile txt || To include system profile in the dump but in TXT format

Note: Whenever you change anything, you should attach new output of gen_debug.

Note 2: It is recommended to update your copy of gen_debug every alternate month (for fixes and new features). To do so, If you are running version 2.1 or above, you can simply type "gen_debug -u" (without quotes) in terminal. If you are running version 2.0 or less, you can use the attached installer script to update your copy.

Note 3: To all the users that are facing IOREG dump failures:
You need to enable the accessibility permissions for the “Terminal”. 
This privacy feature was introduced in macOS Mojave.
Open Sys Prefs > Security & Privacy > Accessibility. Look for “Terminal” and allow access. 

Changelogs:

Regards

install_tools.zip

• Dids Github repo
• CloverHackyColour (Slice) Github repo

Clover Configurator app can be found at the following location:

• Mackie100 repo

This can be a problem for such situations where a vanilla kext has to be replaced in /S/L/E or a file of /S/L/CoreServices has to be patched.

The trick is basically to mount Catalina's root partition in Read-Write (RW) mode instead of Read-Only (RO) mode. This can be accomplished through Terminal with the following command:

sudo mount -uw /

followed a restart of the Finder through Terminal command:

sudo killall Finder

or simply by relaunching the Finder from the Apple menu:

1/ Caching kexts:

Kexts placed in /L/E and/or /S/L/E are cached in the kernel cache (or prelinked kernel) which aims to accelerate boot time. This is the natural and expected mode of operation of the OS. Cached kexts are subject to signature by Apple and must be set with the correct permissions (Cf. our FAQ topics on permissions). Cached kexts will be shown/listed/registered in System Info (ex-SysProfiler) -> Software -> Extensions. Caching kexts is the recommended scheme for all add-on kexts.

• /S/L/E is the location for Apple's own (i.e. vanilla) kexts. Ideally, this should be left untouched by Hackintoshers unless for very specific and rare reasons (eg: patched AppleHDA).
• /L/E is the location for 3rd party/add-on kexts. This is where all kexts we use for our Hackintoshes should go.
•  Add-on kexts should only be placed in either folder, never in both.

2/ Injecting kexts through Clover:

Injected kexts are not cached and will not be shown/listed/registered in System Info (ex-SysProfiler) -> Software -> Extensions. Injecting kexts results in a slightly slower boot than caching kexts (though many would arguably say it's hardly noticeable). Kexts injection operates according to Clover settings on the matter:

• If kext injection is set to Yes, kexts placed in E/C/k/O (or E/C/k/10.xx) will be injected.
• If kext injection is set to No, no injection takes place; obviously...
• If kext injection is set to Detect, kext injection operates according to the presence of FakeSMC in the kext cache (the kext having been properly installed in /L/E or /S/L/E). If present, no injection takes place, if absent, kext injection is performed.
•  If kext injection is used, make sure the kexts aren't cached at the same time.

Clover's E/C/k/O and E/C/k/10.xx are the locations for kexts that Clover injects at boot time:

• E/C/k/O is used to inject kexts regardless of the OS X/macOS version.
• E/C/k/10.xx are used to inject kexts for the given OS X/macOS version and therefore allow different kexts to be injected for different versions.

Apart from the obvious requirement for fresh OS X/macOS installations (and/or updates), kext injection is very useful for recovery purposes (like booting without cache which ignores /L/E) or when testing kexts for instance; if a newly injected kexts causes issues (like a KP), it's very easy to remove/bypass it. On the other hand, kext injection is known to occasionally cause problem because it's not the natural way in which kexts should be loaded. Kext injection is basically a form of forced loading and, sometimes (though rare these days), it does not work. This is why -as stated on numerous occasions by Rehabman himself- Clover should really be set with kext injection in "Detect" mode and contain only the absolutely essential/minimum set of kexts required to boot the system.

My own recommendation is to experiment with kexts through injection and, once kexts are validated, to cache them from /L/E.

Google for this kext injection matter or consult the Clover wiki/InsanelyMac forum. It's all quite widely documented.

Hi Everyone 

All new laptops and OSX causing Distortion/Crackling Sound and these new laptop has combojack instead traditional seperate jacks , so fixing this requires more workaround similar as  linux is doing to work natively in OSX , i remember in July 2016 Goodwin_C  ask me to fix ALC298 (ALC3266) for Dell XPS 9550, after understanding how linux is doing i was able to fix this with help of hda-verb Rehabman Port of linux hda-verb , special thanks to him , so i created a custom SSDT298 to use with CodecCommander this fixed combojack and static noise  from headphone , after few days we found CodecCommander is not good when Speaker changes to Headphone same when Mic changes to Line-In , then commands need to send manually bcoz CodecCommander can't understand changes on OS Level , then i took break from Hack scene in 2017 Goodwin_C found a workaround to fix this issue , so he made ALCPlugFix and implemented same command in this and it was best method to fix this issue so far and using same method till now 

i'm receiving lots of request to fix same issue from very long time for many codecs , so it's time to share this method so it could help you fix this easily according your codec 

Requirements: 

1. Download latest version of CodecCommander https://bitbucket.org/RehabMan/os-x-eapd-codec-commander/downloads/
2. Codec_Dump of your codec from linux use this method mention here 
3. ALCPlugFix https://github.com/goodwin/ALCPlugFix

How to fix Static Noise/Distortion/Crackling issue  :

   1. Copy hda-verb to /usr/bin folder 

   2. Find Pin-ctls in you codec_dump , below is example Pin Complex Nodes for Headphone 

Node 0x18 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
  Control: name="Headset Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Pincap 0x00003724: IN Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_80
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0

so Pin-ctls in headphone nodes is 

Pin-ctls: 0x20: IN VREF_80

 3. now we have to send command to codec using hda-verb use below command in terminal for Headphone :

hda-verb 0x18 SET_PIN_WIDGET_CONTROL 0x20 = (Headphones Pin-ctls: 0x20 from codecDump)

Now you will notice this issue is fixed 

Note : usually you don't need to send command for headphone only but in few case you need to send command to Line-In, Mic or Speaker too ,

you can create Custom SSDT to use with CodecCommander is better approach 

How to fix ComboJack issue:

to fix combojack you need to send additional commands to Line-In (External Microphone) nodes 

1.  First find out which is your Line-In (External Microphone Combojack Node)  is connected to Headphone Jack , below example : codec_dump

Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
  Control: name="Headset Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Pincap 0x00003724: IN Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D3, actual=D3

Node 0x1a [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Headphone Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0001373c: IN OUT HP EAPD Detect
    Vref caps: HIZ 50 GRD 80 100
  EAPD 0x2: EAPD
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c* 0x0d

there is two node 19 and node 1a , we have to use node 1a this is combojack node one jack for Headphone/Mic 

Node 0x19 "Headset Mic Boost Volume"   
Node 0x1a "Headphone Mic Boost Volume"

"Headset Mic Boost Volume"      = External Port (Sperate Mic Jack)    

"Headphone Mic Boost Volume" = ComboJack (One Jack for Headphone/Mic)

2.  Find Pin-ctls in your codec_dump , below is example Pin Complex Nodes for Line-In 

Node 0x1a [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Headphone Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0001373c: IN OUT HP EAPD Detect
    Vref caps: HIZ 50 GRD 80 100
  EAPD 0x2: EAPD
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c* 0x0d

  so Pin-ctls in line-in nodes is 

Pin-ctls: 0x20: IN VREF_HIZ

 3. now we have to send command to codec using hda-verb use below command in terminal for Line-In (External Microphone) :

hda-verb 0x1a SET_PIN_WIDGET_CONTROL 0x20

before send command you need to plug headphone in combojack , this will fix your issue but when you unplug and replug headphone again you need to send command everytime so to fix this use ALCPlufix 

 4. Open ALCPlufix project in Xcode , you need Xcode to build and modify source

now change your node and Pin-ctls as in above image in 3 sections 

hda-verb 0x18 SET_PIN_WIDGET_CONTROL 0x20 (Node18 Headphone)
hda-verb 0x1a SET_PIN_WIDGET_CONTROL 0x20 (Node1a Line-In)

5. Build project and copy ALCPlugFix to alc_fix folder and then run install.sh file

Now you don't need to worry about switching between combojack to mic 

Note : for better performance you must use Custom SSDT + CodecCommander + ALCPlugfix 

if still combojack doesn't work for you, then you need good patch for your codec, feel free ask here 

PS: most of codec in my git repo using this method and working good so far https://github.com/insanelydeepak/cloverHDA-for-Mac-OS-Sierra-10.13

you can switch between commands to get best result , below are pin-ctls i have found in different codec_dumps so far , you can use any below and this will work for you  

Pin-ctls: 0xc0: ALC292 (ALC3232)
Pin-ctls: 0x24: ALC288 (ALC3263)
Pin-ctls: 0x20: ALC298 (ALC3266)
Pin-ctls: 0x25: ALC255 (ALC3234)
Pin-ctls: 0xc0: ALC256 (ALC3246)
Pin-ctls: 0x40: ALC299 

you can use this method on AppleALC, cloverHDA or DummyHDA ,

latest version of AppleALC has feature to send command to codecs like CodecCommander , you can modify AppleALC info.plist to stop using CodecCommander, 

also while using AppleALC if you need  CodecCommander you must use SSDTALC.aml , otherwise AppleALC will conflict with CodecCommander

latest version of CodecCommander is aware of AppleALC so you don't SSDTALC.aml at all , you can use both at same time 

Hope this guide could help you in fixing these issue to enjoy a good sound 

Regards

Credits:
RehabMan 

when clicking on the 1st 2 errors, they'll take you to these set of codes

To fix the errors,  I created this patch which you can just apply with latest version of MacIASL

This will fix all 3 errors listed above. Enjoy!

This guide is there to be used as a reference or a starting point for anyone trying to install macOS on a non Apple machine.

This guide covers installation using CLOVER as it is very much the standard now. Also, most of the systems nowadays are UEFI enabled and CLOVER can take full advantage of it.

Things you will need:

• An USB Drive with capacity of 16GB or larger (8GB might work too)
• An existing macOS install (Real mac/Hackintosh)
• A downloaded macOS Installer
• An internet connection
• A little bit of your time

Note: It is not recommended to create a bootable USB using a VM as it corrupts the installer in some cases. Although If you have no other option at your disposal you may try resorting to it. You have been warned.

BIOS Settings:

When it comes to installing OS X on a non Apple machine BIOS settings play a very important role. Here are a few common settings that should be changed if they exist

• VT-d - Disabled (You may use dart=0 if this option is not in the BIOS)
• DvMT - 64MB (If you can change this setting, please do. If you set DvMT > 64MB you will have to patch framebuffer to take advantage of it)
• DEP - Enabled
• SATA Mode - AHCI (Very important)
• Secure Boot - Disabled
• Legacy Boot - Disabled (I rarely boot legacy, you may leave it Enabled though, no harms)
• CSM Module - Disabled (Available as "Launch CSM" on ASUS. You may try toggling it. It tends to help in cases of garbled screen)
• Fast Boot - Dsiabled
• Boot from USB - Enabled

Creating the installer USB:

It is obvious but writing it anyway, make sure that if there exists any data on USB drive that will be erased. Take a backup before attempting the steps below.

There are two ways of creating the installer USB.

1. createinstallmedia Method (can be used on Real Macs. Only method that gives you a OS X recovery partition. Preferred.)

2. BaseBinariesClone Method (Use when trying to boot legacy system or if the above method doesn't work for you.)

Please note that we are going to use a install creator utility written by me for both of the above methods. In that:

New Way refers to createinstallmedia

Old Way refers to Base Binaries Clone

So, choose your options accordingly.

Note: Base Binaries Clone doesn't work for 10.13.x or above

Getting the script:

`

Open up terminal and type:

cd ~/Desktop
curl -o bkit https://raw.githubusercontent.com/black-dragon74/Bkit/master/bkit
chmod a+x bkit

`

You will have the utility on your Desktop.  Now we need to get hold of a few utlities:

Download CLOVER from here

Download FakeSMC from here

Download HFSPlus.efi from here

If preparing for Sierra or above you might need Lilu and IntelGraphicsFixup

Laptop Specific Note: I prefer to use external mouse and keyboard when installing macOS. If you want to use your internal keyboard and trackpad you might need VoodooPS2Controller. (Works only for Trackpads on PS2 Bus. You may try VoodooI2C for trackpads on I2C bus)

For Elan1200 I2C trackpad use the kext attached in my ELAN1200 guide at: https://osxlatitude.com/index.php?/topic/10165-guide-elan1200-i2c-trackpad/

Formatting USB and Installing Clover:

Time has come to invoke Bkit. Open terminal and type

~/Desktop/bkit

`

Now just keep following the instructions from the script:

• Choose your preferred way (New way or Old Way)
• Choose macOS version (Bkit supports 10.9 - 10.13. Requires Install macOS xxx.app in /Applications)
• Press Y to agree to the warning that says USB data will be erased.

Now, Bkit will ask you for your USB device's disk identifier. Here is how to find the same. Open terminal and type:

diskutil list external

You will get a list of external USB devices along with disk identifier like, /dev/disk1 or /dev/disk2

You don't have to write full /dev/disk1 just type the "diskx" part. Like, for /dev/disk2 I would type disk2 in Bkit.

The script will now verify if the disk is indeed an external one (to save from your data loss it is used as a failsafe method).

Now it will ask you to install clover then type c (continue).

Installing CLOVER to USB for UEFI:

• Open clover installer package and click on Continue.
• You will get a README. Select Continue.
• Now you will get a screen to select Install location. Choose "Change Install Location"
• Now select your USB drive and click continue
• You will get back to previous screen. Select "Customize"

Tick the following options:

• Install for UEFI booting only
• Select themes if you would like so (I use BGM)
• Select Drivers64UEFI > AptioMemoryFix (Latest build as of Sat Mar  3 19:31:12 IST 2018 is attached to this post)

Now click on "Install". Punch in your password and press ENTER (Return)

Installing CLOVER to USB for Legacy:

• Open clover installer package and click on Continue.
• You will get a README. Select Continue.
• Now you will get a screen to select Install location. Choose "Change Install Location"
• Now select your USB drive and click continue
• You will get back to previous screen. Select "Customize"

Tick the following options:

• Install CLOVER in the ESP
• Boot-loader > Install boot0af in MBR
• Clover EFI > EFI 64bits SATA
• Select themes if you would like so (I use BGM)
• Select Drivers64UEFI > OsxAptioFixDrv (You may try OsxAptioFix2Drv if it doesn't work for you)

Now click on "Install". Punch in your password and press ENTER (Return)

Once finished, click on Close and get back to terminal where Bkit is waiting for our response.

Type continue/c at Bkit's prompt. It will now verify CLOVER installation and then proceed to copy installation files.

Please DO NOT close Terminal until you get confirmation message from the tool. It may take 5-10 mins for the script to finish (might take longer on slow machines)

A successful run looks like this:

Preparing to boot USB:

Now as we are mostly done with everything, in order for CLOVER to be able to boot macOS install it needs the kexts and a config.plist file.

You have already downloaded the required kexts above. Unzip them and then open your USB drive's EFI partition.

Copy the unzipped kexts and then paste then into: USB's EFI/EFI/CLOVER/kexts/Other

Copy downloaded HFSPlus.efi in: USB's EFI/EFI/CLOVER/drivers64UEFI (VBoxHfs is disabled as it is not that reliable)

Now we need to install a proper config.plist file. Download the one attached to this post and then paste it in: USB's EFI/EFI/CLOVER

Make double sure that the name of the file you just pasted is "config.plist". CLOVER won't read any other config file.

Booting USB:

• Plug your USB device into a USB port (USB2 port recommended)
• Keep pressing your BIOS hotkey at POST screen (Esc key for ASUS laptops)
• Select "UEFI: Your USB"
• You will get CLOVER boot screen. (Hint: You may press F4 now to dump origin ACPI tables. It is required later)
• Press ENTER or wait for 5 seconds to boot automatically.

General notes:

• Bkit can also be used to create installer for real macs. Use "bkit -nc" arg for that.
• You might consider having ethernet connected while installing macOS. Download kexts for (Realtek | Intel) and paste them in USB's EFI/EFI/CLOVER/kexts/Other
• The plist file just gets you to installer screen. It does nothing even close to a full install.
• If you get a reboot it is likely due to DvMT prealloc set to less than 64MB. You may use IntelGraphicsDVMTFixup with Lilu to overcome this issue. However, after installing you must patch framebuffer as IntelGraphicsDVMTFixup has a heavy reliance on framebuffer data and will panic when you use patches for HDMI or Cursor Bytes.
• If you get no device to boot in CLOVER screen it is surely due to missing HFSPlus.efi (Double check that you have it)
• If you get some error related to window server it is because of your Nvidia/AMD GPU trying to load up. To get around you will have to disable the device using ACPI patching (Will save it for some other day)

Problem Reporting:

If you face any problems please post them below. As this is a preinstall process you won't be able to get any logs or debug info hence, post your issue with screen capture (photo) of the panic along with your USB device's CLOVER folder.

I'll be glad to help.

Cheers

config.plist.zip

AptioMemoryFix.efi.zip

# Change working directory
cd ~/Downloads

# Make script executable
chmod a+x get_edid.sh

# Run and get EDID to inject
./get_edid.sh ~/Desktop/DisplayProductID*

`
This script wil give you EDID you need to inject using CLOVER, like:

 
Copy that EDID and paste it in your config.plist under Graphics > EDID > Custom (You can use clover configurator as that will save you from manual PLIST editing which is not recommended for novice users)
 
Also, set Boolean Inject to True (YES) under config.plist > Graphics > EDID.
 
See below screenshots for reference:
 
Any Plist Editor(Xcode):

 
Clover Configurator:

 
Reboot and Voilà! You won't face that dreaded issue ever again until you remove custom EDID. LOL.

You can verify if the EDID is being injected by opening terminal and typing:

ioreg -l | grep "IODisplayEDID" 

`

The output should match the output of get_edid.sh

Problem Reporting:

See How to generate proper problem reporting files

 
Note: This issue mostly seems to effect machines running High Sierra on Kabylake hardware (maybe Skylake too?). I have personally tested this on Sierra (with and without skylake spoofing) turns out that Sierra is not affected by this.

Note: Upon booting up with custom EDID in place you will see that your colors are not such bright and crisp. YMMV. (Coz our's isn't a Apple branded display  ). To fix that, open system preferences > Display. Select "Color" tab and choose "Apple RGB Display"

Hope this helped someone!

Regards

get_edid.zip

• verify volumes arrangement and identify main + recovery partition disk identifier. The recovery partition will directly follow the main volume to which it relates.

diskutil list

• reformat recovery partition under HFS+ type and new name (no space)

diskutil eraseVolume HFS+ <new name> <disk identifier> (eg: [...] Blank disk0s3)

• recover ex-recovery/Blank partition disk space by merging it with its associated main volume (listed right above it).

diskutil mergePartitions HFS+ <main Volume> <main disk id> <blank disk id> (eg: [...] Sierra disk0s2 disk0s3)

NB: Partitions have to be sequential to be merged. For help on the diskutil command, type man diskutil.

• verify CoreStorage status and identify volume

diskutil list

• if logical volume found/listed, revert to legacy volume mode

diskutil CoreStorage revert <disk identifier> (eg: disk1)

• verify return to legacy mode

diskutil list

NB: For help on the diskutil command, type man diskutil.

This is achieved through the following Terminal commands:

sudo pmset -a hibernatemode 0

`

To delete the sleep file:

sudo rm -f /var/vm/sleepimage

`

To point the sleep file towards null device (though sleep file may still re-appear):

sudo pmset -a hibernatefile /dev/null

`

To verify hibernation setup:

pmset -g

Graphics acceleration can be verified through the following (non-exhaustive) actions:

• Translucent Finder's bar (most visible from Snow Leopard to Mavericks)
• LaunchPad through Dock icon (clicking in and out of LaunchPad should be quick and totally smooth)
• DVD player app -> Help Menu -> Show Supported Features (all should be enabled)
• Desktop switching through Ctrl-Up/Ctrl-Down/Ctrl-Left/Ctrl-Right (should be quick and smooth)
• Desktop and Screen Saver PrefPane (all desktop pictures and screen savers should show Ok)

Without graphics acceleration, system will feel laggy and graphics glitches will occur.

sudo trimforce enable

`

For earlier versions, the IOAHCIBlockStorage kext must be binary patched to suppress whitelisting for Apple-branded SSDs only:

Find:       004150504c452053534400     (=> " APPLE SSD ")
Replace by: 0000000000000000000000     (=> "           ")

NB: this patch can also be used for Yosemite 10.10.4 and later.in

I believe the patch was 1st reported at InsanelyMac. It's one of the kext patches provided by default in Clover Configurator.

sudo chmod -Rf 755 /S*/L*/E*
sudo chmod -Rf 755 /L*/E*
sudo chown -Rf 0:0 /S*/L*/E*
sudo chown -Rf 0:0 /L*/E*

`
To rebuild the cache, type the following Terminal command:

sudo touch -f /S*/L*/E*
sudo touch -f /L*/E*

The cache should then automatically rebuild itself.