Contribute
Register

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

Excellent guide, helps us newbies to enter a little better this utility :clap:
 
AppleALC

[...] you should remove [...] DSDT Edits ...
On my HM67 mainboard the IRQ Fix (FixTMR, FixRTC, FixIPIC & FixHPET) is still needed for AppleALC to work.
AirportBrcmFixup

If necessary, you can over-ride the default MacOS WiFi local and explicitly set the country code for your WiFi device using the boot argument brcmfx-country=XX, this is sometimes necessary to get 5Ghz WiFi working at full speed with your router.
Not setting this option results in US by default.

Bildschirmfoto 2018-09-29 um 23.32.17.png
Always had it set to my location (brcmfx-country=DE), but still had slow rates at ~25 kbit/s. I just discovered minutes ago that setting brcmfx-country=#a solves this (>200 kbit/s now).

Does anybody know how to set this option via AddProperties/Arbitrary?!

Bildschirmfoto 2018-09-29 um 23.41.49.png
 
I just discovered minutes ago that setting brcmfx-country=#a solves this (>200 kbit/s now) .... Does anybody know how to set this option via AddProperties/Arbitrary?

As it states in the guide brcmfx-country is a boot argument not a device property.

Cheers
Jay
 
As it states in the guide brcmfx-country is a boot argument not a device property.

Cheers
Jay
Please see the highlighted text in the second thumbnail. :)
 
Updated post #12.

I can confirm this for for my DW1550 (Broadcom BCM94352HMB). In addition, after disabling ACPI->DSDT->Fixes->FixAirport and Devices->FakeID->WIFI the card is now marked as built-in.

Faced a few problems when download big files. They were useless due to corrupted files. Re-enabling ACPI->DSDT->Fixes->FixAirport fixed the problem. Therefore, the fix seems to be still needed.
 
@Henties,

You could try asking the WEG Devs for confirmation on the WEG official support thread :-

https://www.insanelymac.com/forum/topic/325987-whatevergreen-support-topic/

Would be interesting to know what they say so i can update the guide if necessary.

Cheers
Jay
I have finally got this reply from @scj312 in the other "universe" concerning the validity of the shikigva=xx bootflag.

"You can still use shikigva boot args with WhateverGreen exactly the same as you could before. On my system I don't need to use the boot arg."

The fact that the old shikigva boot flags are not listed, although seemingly still usable' makes me view the "merged" Whatevergreen.kext with suspicion. It still seems only to be a half baked egg. I am not presently using the shikigva=xx flag and have so far not been able to detect anything untoward with my Skylake build as is evident from the attached screenshot depicting a continuous 70 hour uptime and sleep behavior that is consistent with the usage pattern spanning that period. I am happy and will therefore leave my configuration as is. As the saying goes. If it ain't broken don't fix it, no sorry that is wrong, it should actually read, If it ain't broken break it :) of cause only if one is stupid enough :)
Greetings
Henties
 

Attachments

  • Screenshot 2018-10-03 at 8.46.44 AM.png
    Screenshot 2018-10-03 at 8.46.44 AM.png
    111.3 KB · Views: 159
Last edited:
I have finally got this reply from @scj312 in the other "universe" concerning the validity of the shikigva=xx bootflag .... "You can still use shikigva boot args with WhateverGreen exactly the same as you could before. On my system I don't need to use the boot arg."

@Henties,

Thanks for update ....

The fact that the old shikigva boot flags are not listed, although seemingly still usable' makes me view the "merged" Whatevergreen.kext with suspicion. It still seems only to be a half baked egg. I am not presently using the shikigva=xx flag and have so far not been able to detect anything untoward"

The boot flags are still listed in the "Manual" sub folder on WhatEverGreen's Git-Hub page, however these are essentially the old readme.md files from each of the merged plug-in's. As I previously mentioned in the case of shikigva I believe thats it's enabled by default if applicable to the IGPU as there is no real reason not use it, I suspect that the boot flag is still left in there just incase a user needs to over-ride the defaults, I suspect the same is true for the other merged plug-in's in that commonly used options are enabled as default hence the reason WhatEverGreen works so well with minimal configuration on many systems.

Cheers
Jay
 
I suspect the same is true for the other merged plug-in's in that commonly used options are enabled as default hence the reason WhatEverGreen works so well with minimal configuration on many systems.
Thanks for your explanation, now this all makes more sense to me.
Cheers
 
I have finally got this reply from @scj312 in the other "universe" concerning the validity of the shikigva=xx bootflag.

"You can still use shikigva boot args with WhateverGreen exactly the same as you could before. On my system I don't need to use the boot arg."

The fact that the old shikigva boot flags are not listed, although seemingly still usable' makes me view the "merged" Whatevergreen.kext with suspicion. It still seems only to be a half baked egg. I am not presently using the shikigva=xx flag and have so far not been able to detect anything untoward with my Skylake build as is evident from the attached screenshot depicting a continuous 70 hour uptime and sleep behavior that is consistent with the usage pattern spanning that period. I am happy and will therefore leave my configuration as is. As the saying goes. If it ain't broken don't fix it, no sorry that is wrong, it should actually read, If it ain't broken break it :) of cause only if one is stupid enough :)
Greetings
Henties
@Henties,

Thanks for update ....



The boot flags are still listed in the "Manual" sub folder on WhatEverGreen's Git-Hub page, however these are essentially the old readme.md files from each of the merged plug-in's. As I previously mentioned in the case of shikigva I believe thats it's enabled by default if applicable to the IGPU as there is no real reason not use it, I suspect that the boot flag is still left in there just incase a user needs to over-ride the defaults, I suspect the same is true for the other merged plug-in's in that commonly used options are enabled as default hence the reason WhatEverGreen works so well with minimal configuration on many systems.

Cheers
Jay

shikigva kernel flag parsing related code in WhateverGreen:
Code:
    int bootarg {0};
   if (PE_parse_boot_argn("shikigva", &bootarg, sizeof(bootarg))) {
       forceOnlineRenderer     = bootarg & ForceOnlineRenderer;
       allowNonBGRA            = bootarg & AllowNonBGRA;
       forceCompatibleRenderer = bootarg & ForceCompatibleRenderer;
       addExecutableWhitelist  = bootarg & AddExecutableWhitelist;
       replaceBoardID          = bootarg & ReplaceBoardID;
       unlockFP10Streaming     = bootarg & UnlockFP10Streaming;
   } else {
       if (PE_parse_boot_argn("-shikigva", &bootarg, sizeof(bootarg))) {
           SYSLOG("shiki", "-shikigva is deprecated use shikigva %d bit instead", ForceOnlineRenderer);
           forceOnlineRenderer = true;
       }

       // Starting with 10.13.4 Apple has fixed AppleGVA to no longer require patching for compatible renderer.
       if ((getKernelVersion() == KernelVersion::HighSierra && getKernelMinorVersion() < 5) ||
           getKernelVersion() < KernelVersion::HighSierra) {
           autodetectGFX = cpuGeneration == CPUInfo::CpuGeneration::SandyBridge ||
           cpuGeneration == CPUInfo::CpuGeneration::IvyBridge ||
           cpuGeneration == CPUInfo::CpuGeneration::Broadwell ||
           cpuGeneration == CPUInfo::CpuGeneration::Skylake ||
           cpuGeneration == CPUInfo::CpuGeneration::KabyLake;

           if (autodetectGFX) {
               forceCompatibleRenderer = true;
               addExecutableWhitelist = getKernelVersion() >= KernelVersion::Sierra;
           }
       }

       DBGLOG("shiki", "will autodetect autodetect GPU %d whitelist %d", autodetectGFX, addExecutableWhitelist);
   }
 
Hi @RehabMan Thanks for the code snippet showing how the kernel flag parsing code is implemented in WhateverGreen. So as from 10.13.4 and provided the 2nd last "if construct with the 5 OR conditionals" of the code snippet stuffs "something valid into autodetectGFX then the last if construct will set forceCompatibleRenderer = true, thus automating what we had to do manually with "shikigva kernel bootflags in the past.
This is great thus hiding the setup complexity from normal hacking earthlings like me.
Hoping my interpretation is correct, am a bit rusted as far as coding is concerned.
I would probably have used a "case construct" to achieve the same thing. There are many ways to kill a cat though.
Greetings
Henties
 
Last edited:
Back
Top