An iDiot's Guide To Lilu and its Plug-ins

[jaymonkey]

@dragonmel,

For your El-Cap volume you could try the SSDT method to disable the dGPU :-

[FIX] "Window Server Service only ran for 0 seconds" with dual-GPU

Overview If you have a dual-GPU (Intel+Nvidia or Intel+AMD Radeon), you may have trouble reaching the macOS High Sierra installer. It is a new bug in the system somewhere that stalls boot if the VESA drivers try to connect to the secondary (discrete) graphics device. There are essentially...

www.tonymacx86.com

We generally recommend that method to disable a Nvidia card in Mojave but the method should theoretically work for a AMD GPU in an earlier version of MacOs. Allowing users to keep the Nvidia card installed for use with Windows but to completely disable it at a ACPI level in MacOS.

As for your issue with unwanted UEFI entry ... that's a strange one and usually the EFI Shell/BCFG method works.
As a last resort have you tried a CMOS reset ? (be sure to make a note of your BIOS settings first)

Cheers
Jay

 

[dragonmel]

@jaymonkey
ok.. I backed up and deleted my efi partition and installed the latest clover build

this time I kept the installed clover config.bios instead of replacing it straight away with mine.

I removed my edited dsdt.aml and nvram.. again .. deleted everything from the efi on the only drive attached to the system..

deleted rc.boot and rc.shutdown nvram related scripts but I believe I kept the rc script to block darkwake

and guess what.. native NVRAM .. I can change a test variable and it persists...

so its likely then when I first installed and had clover 5045 set up with the same osxaptiodrvfix3 that the apple update must have written something to my motherboard that I can't remove.

I noticed that my apple folder on EFI had a lot of updaters and such

still working out the kinks of what renames and patches to apply in clover configurator but right now I seem to have gotten a boot, shutdown, perhaps auto shutdown.. boot seems to stop sign less but I have had a couple wakes along the way that result in a hung start, no system operating and the graphics card looking like its not initiating ..

oh..also.. kinda weird if I am reading the log right.. but I installed UEFI only, and have the DX58so bios set for UEFI boot, and selecting the UEFI drive in the boot menu but the log says it booting boot.ini I think and not uifiboot64.efi or whatever that file is ...

i know intel early UEFI was half baked but it looks like its bios booting?


I also think its using a generic frame buffer.

do you think you could help me troubleshoot a bit and suggest some fine tuning say tomorrow after some additional testing? just let me know what files you need

thanks

 

[dragonmel]

hey @jaymonkey

still looks like I am stuck with generic frame buffers

ART,AMD,RadeonFramebuffer@0

WEG renames it GFX0@0 on my PEG3@3 on the PCI0 ... but I found this

real Mac Pro 5,1 don't use GFX0

SSDT GPU (Graphics Card) Injection

Work in progress... Updated step 3b and files 2/22/2017. If you have come to this guide to deal with a "Black Screen" issue, please read this post first: http://www.tonymacx86.com/graphics/183113-black-screen-macpro-6-1-imac-15-imac-17-system-definition.html You may also want to take a look at...

www.tonymacx86.com

they use PSX1@0

is this still a thing? or has WEG superseded it.. I am experimenting with the SSDT method of getting the frame buffer injected but I am not having success and I don't know if real mac pro 5,1 machines use these FB names of something different

additionally, system profiler is showing the graphics card on the PCIe at 8GT/s but my board is 5GT/s

don't know if any of this effects power management

 

[jaymonkey]

still looks like I am stuck with generic frame buffers

ART,AMD,RadeonFramebuffer@0

WEG renames it GFX0@0 on my PEG3@3 on the PCI0 ... but I found this

is this still a thing? or has WEG superseded it.. I am experimenting with the SSDT method of getting the frame buffer injected but I am not having success and I don't know if real mac pro 5,1 machines use these FB names of something different

@dragonmel,

WEG has always injected a GenericFramebuffer with AMD GPU's .... its not an issue, you do not loose any performance or features .. it's just the way WEG does things.

I did know that the MacPro5,1 SMBIOS uses PSXx@x as a ACPI device name/path for a dGPU ...

However I've never personally used the MacPro5,1 SMBIOS so cant really advise you on if having it renamed as GFX0 is an issue or not .. I guess if the Vega 56 is working in MacOS with a ACPI name of GFX0 then it's not an issue.

The WEG devs are pretty hot on AMD support, after all WEG was originally only for AMD GPU's so they must have their reasons for doing it ...

Cheers
Jay

 

[dragonmel]

@dragonmel,

WEG has always injected a GenericFramebuffer with AMD GPU's .... its not an issue, you do not loose any performance or features .. it's just the way WEG does things.

I did know that the MacPro5,1 SMBIOS uses PSXx@x as a ACPI device name/path for a dGPU ...

However I've never personally used the MacPro5,1 SMBIOS so cant really advise you on if having it renamed as GFX0 is an issue or not .. I guess if the Vega 56 is working in MacOS with a ACPI name of GFX0 then it's not an issue.

The WEG devs are pretty hot on AMD support, after all WEG was originally only for AMD GPU's so they must have their reasons for doing it ...

Cheers
Jay

thanks Jay..

right now.. things look improved.. but I am using a big hammer.. lots of hot patches and renames are by default turned on during the clover install

I had a restart causing a power off sudo cmos reset looking event but it didn't clear cmos settings but did bring up a cmos failures to boot message. I have reuse FFFF, fixRTC, apple RTC, gen P/C states etc turned on

seems like changing the shutdown/reset values to the PCI rail might have fixed that up. and if I recall I was doing that with my previous install

don't know if I should leave generate P/C states on since the w3680 is a known proc, and the x58 chipset are both used in real Mac Pro 5,1

I let it sleep over night and I got a clean wakeup 7 hours later. I am seeing less stop sign events at boot...

its odd that I can now use NVRAM with just the clover driver and no RC. scripts... I am convinced this is somehow related to how the apple update might have written or partially written a firmware update to my board.

so many things change... so little FORMAL documentation and a lot of questionable data in threads

so I am indeed just letting clover and LILU / plugins do their thing. there were a couple built in renames turned on by default most of which clover is telling me didn't execute. I had to modify SAT to SATA as my board has SAT1 SAT2 I think and the second sat I don't believe is supported and I have it disabled in bios..

funny that I don't think that clover really abides by some of these settings

for example I have ECC memory (non buffered) which should permit me to enable ECC in bios but it always shows as disabled in System Information. If I enable ECC in bios clover boot log tells me that turbo boost and other features of the cpu are disabled so I leave ECC disabled in bios..

however I am not using the required TyMce disable patch which is required for mac pro5,1 SMBIOS definitions to avert a kernel panic without ECC ram.. but I never get that panic or TyMCE messages in the logs.. so even though BIOS has ECC disabled and system profiler says its disabled.. it must be enabled

the standard install of clover has almost all DSDT hot patches active so I am sure that there are some that I don't need.

so you don't think having the generic frambuffer is going to cause performance or reboot/wake issues?

right now I have a 42" Seiki 4k monitor attached to a DP with a Club3d DP1.2 to HDMI adapter and a gateway .. old gateway 1920x1200 FDH monitor attached to HDMI. it did wake from sleep this am so a couple more wakes like that and perhaps we are out of the woods.

I wonder if I should buy a DP 1.4 adapter instead?

on my previous setup with the gtx660 I had to generate custom profiles for the Seiki 4k in El Cap to get it working.. and 4k60 had to stay around 530 for total bandwidth otherwise it wouldn't work.. sound over HDMI would only work at frame rates below 50. 4k60 would garble the audio

in Mojave I still have switchresx installed, but I deleted the custom resolutions and the standard 4k60 profile with a bandwidth of 599ish seems to work fine and HDMI audio is clean even at 60.

I have not tested switching the display framerate to 30 and 24 since re-installing clove from scratch but it was not working before

switching framerate would horribly corrupt the video picture, sometimes switching inputs back and forth or power cycle the Seiki would fix it ... seems like the Windows crowd also has issues with the Vega .. similar type issues of black screen and not fetching the EDID properly at display switching, sleep/wake etc..

I think that perhaps that might be some of our issues on OS X as well..

 

[jaymonkey]

right now.. things look improved.. but I am using a big hammer.. lots of hot patches and renames are by default turned on during the clover install.

the standard install of clover has almost all DSDT hot patches active so I am sure that there are some that I don't need.

@dragonmel,

Good to know your making progress ...

If you look at Clovers pre-boot log file you can see which AHCI fixes/renames are actually doing something and those that are not, it's towards the end of the log file .. you can see if Clover found a match (or not) and applied a fix.

You can then disable the fixes/renames that are not used ..

so many things change... so little FORMAL documentation and a lot of questionable data in threads

Yes, unfortunately thats always been the case ... it's going to get even worse once the OpenCore boot loader goes main stream and becomes the new default standard, it's very particular about the config file syntax. It is a great boot-loader and you can ditch a lot of unnecessary patches that we use in Clover but man can it be finicky.

so you don't think having the generic frame buffer is going to cause performance or reboot/wake issues?

Yes, I've tested Vega hacks with the generic frame buffer as injected by WEG and also systems configured with a specific frame buffer (Kamarang) injected via SSDT and there is no performance loss or feature difference .... at least none that I could find in my testing.

in Mojave I still have switchresx installed, but I deleted the custom resolutions and the standard 4k60 profile with a bandwidth of 599ish seems to work fine and HDMI audio is clean even at 60.

Most likely due to the improved Vega drivers that came with 10.14.5+

Just keep chipping away at the config and streamlining things ..

One useful tip ... always keep a copy of your last know working config.plist in /EFI/Clover .. rename it something like "config-last.plist". That way you can always boot MacOS using a known working config. You can select which config.plist Clover will use by selecting "Options" in Clover, then select "Configs" and then select "config-last.plist", return to the main Clover menu and boot MacOS as normal.

Cheers
Jay

 

[dragonmel]

@dragonmel,

Good to know your making progress ...

If you look at Clovers pre-boot log file you can see which AHCI fixes/renames are actually doing something and those that are not, it's towards the end of the log file .. you can see if Clover found a match (or not) and applied a fix.

You can then disable the fixes/renames that are not used ..




Yes, unfortunately thats always been the case ... it's going to get even worse once the OpenCore boot loader goes main stream and becomes the new default standard, it's very particular about the config file syntax. It is a great boot-loader and you can ditch a lot of unnecessary patches that we use in Clover but man can it be finicky.




Yes, I've tested Vega hacks with the generic frame buffer as injected by WEG and also systems configured with a specific frame buffer (Kamarang) injected via SSDT and there is no performance loss or feature difference .... at least none that I could find in my testing.




Most likely due to the improved Vega drivers that came with 10.14.5+

Just keep chipping away at the config and streamlining things ..

One useful tip ... always keep a copy of your last know working config.plist in /EFI/Clover .. rename it something like "config-last.plist". That way you can always boot MacOS using a known working config. You can select which config.plist Clover will use by selecting "Options" in Clover, then select "Configs" and then select "config-last.plist", return to the main Clover menu and boot MacOS as normal.

Cheers
Jay

thanks for the help Jay...

still having an issue during reboot, not shutdown, where the reboot appears to be going well and just before the splash screen would come up, the computer power cycles and boots... no bios warning this time about unable to boot / revert to last know bios y/n ... I have checked just about anything I can't think would be involved in the fix...

I have not tried setting the shutdown/reboot addresses to 0/0 to use FACT table
might have to try that as the default and pci rail addresses result in issues on reboot

 

[LuizMeliga]

I can't get graphical acceleration on igpu using SMBIOS 19.1 or 19.2. I tried with the indicated ig-platform, but it doesn't work. When I use smbios 18.3, it activates without having to use ig-platform.

Does anyone know how to solve? I am using 10.13.6 with a GTX 1080 and an 8700k.

 

[jaymonkey]

still having an issue during reboot, not shutdown, where the reboot appears to be going well and just before the splash screen would come up, the computer power cycles and boots... no bios warning this time about unable to boot / revert to last know bios y/n ...

@dragonmel,

Hummmm that does not sound great ... not sure what else to suggest other than what you have already tried.

I'm guessing you have already tried Clovers "FixShutdown" ACPI patch .. although it's know to cause issues on some systems. You could also try enabling Clovers "Halt Enabler" Option ...

Make sure you have "Fix Headers" option enabled ...

You should also try setting the shutdown/reboot addresses to 0/0 to use FACT table as you suggested.

Cheers
Jay

 

[jaymonkey]

When I use smbios 18.3, it activates without having to use ig-platform.

@LuizMeliga,

The latest versions of Lilu + WhatEverGreen have a much improved IGPU Auto Detect/Auto Configure feature and works well on most systems without having to explicitly define IGPU Device Properties in config.plist. Having said that I believe it's still good practice to define them as a belt and braces approach and could avoid issues in the future with a buggy/faulty release of Lilu and/or WhatEverGreen.

I recently updated the guide with info on WEG's Auto Detect/Auto Configure feature as it now has a better chance of working (as you have experienced) ....

Cheers
Jay