Jump to content

RehabMan

RehabMan

Member Since 25 Jun 2012
Offline Last Active Today, 12:17 AM
*****

#2448822 Clover General discussion

Posted by RehabMan on 21 June 2017 - 04:58 PM

In this case, I think it's better for us to follow Apple, not enabling HWP for now on desktops.Ah yes... Just adding related power features.It won't be too complex I guess, with the help of some kexts that help us write corresponding MSRs. (I don't own any Skylake+ desktops to test though...) IMO it must bring negative effects to performance without SpeedStep. HWP can be just a small part of PM, it doesn't really matter. :) No special kext necessary for HWP enabling (including after sleep/wake).  The code is already in the kernel/X86PlatformPlugin.Agree probably best to avoid HWP on desktop (even though it works), as Apple is not using it.  But it is still interesting to experiment with it...

#2448431 Clover General discussion

Posted by RehabMan on 20 June 2017 - 10:37 PM

I saw iMac17,1, iMac18,x and even iMac19,1 (the coming iMac Pro) have no "hwp" power feature in their FreqeuncyVectors, unlike MacBook(Pro).Maybe just like @Slice said, the mechanism is a little bit different... It is why I added HWP to my iMac17,1 X86PlatformPlugin injector kext.

#2448378 Clover Bug/Issue Report and Patch

Posted by RehabMan on 20 June 2017 - 07:47 PM

Sure? You can take XNU sources and find all kernel flags in them.For example sSafeBoot = PE_parse_boot_argn("-x", bootArgBuffer, sizeof(bootArgBuffer)) ? true : false;There is no "-f". The bootargument was introduced in Chameleon. It is the bootloader that load kernel and kext into memory by itself. Later version also loaded kernelcache or extensions.mkexts if not "-f" specified#define kOldSafeModeFlag "-f" if ( getValueForKey( kOldSafeModeFlag, &val, &cnt, &bootInfo->bootConfig ) ) { gBootMode = kBootModeSafe; trycache = (((gBootMode & kBootModeSafe) == 0) &&The flag has no relation to boot.efi or to kernel any version.The flag "-f" absent in Clover since first revision. -f still having a measured effect here. The situation is quite simple:- AppleHDA injector installed, all appropriate Clover patches present, layout-id injected, etc.- but it is not working (AppleHDA doesn't load)- solution: boot with -f, re...

#2448171 Clover Bug/Issue Report and Patch

Posted by RehabMan on 20 June 2017 - 02:18 PM

What exactly does it do now? I knew it was still present in boot.efi, but not what it was actually used for after prelinkedkernel was made the only way to boot. This is how it is used... (no idea what it is actually doing)...It is very common for AppleHDA to "fall out of cache" during updates, or when installing kexts (no idea why...)After that happens, Clover KextsToPatch will not apply, as it will not be loading from kernel cache.The only way to jumpstart things at that point, is to boot without caches (kernel flag -f), which causes AppleHDA to load.  Following that, a kernel cache rebuild will get it back in cache, where you can then boot normally (with cache) with the AppleHDA KextsToPatch being applied... until the next time it breaks. Bottom line:- kernel flag -f is still useful on current macOS- and Clover is still used with older systems (as I mentioned) anyway (even if -f stopped doing anything in 10.13+)- therefore, the option in Clover should never have bee...

#2448155 Clover Bug/Issue Report and Patch

Posted by RehabMan on 20 June 2017 - 01:33 PM

If I remembered correctly, no cache mode got deprecated since a beta version of 10.12? Kernel flag "-f" not deprecated. As I wrote, it still does something and is still useful.It may not do exactly what it used to, but still useful.And besides that, Clover is still used with older OS X.

#2447724 Clover Bug/Issue Report and Patch

Posted by RehabMan on 19 June 2017 - 09:17 PM

I suggest we bring back "Boot without caches"...- it is still useful on current versions... although it doesn't do what it used to, -f is still needed for cases using injector kexts with symlinks (aka. "Dummy kexts")- and it is also useful for older versions of OS X, where still works as it originally did (I have a system that can run all versions SL->Sierra) The diffs:--- rEFIt_UEFI/entry_scan/loader.c (revision 4093)+++ rEFIt_UEFI/entry_scan/loader.c (working copy)@@ -759,7 +759,6 @@     }    -//    AddMenuCheck(SubScreen, "Without caches",       OSFLAG_NOCACHES, 69); //    AddMenuCheck(SubScreen, "With injected kexts",  OSFLAG_WITHKEXTS, 69);     AddMenuInfo(SubScreen, L"=== boot-args ===");     if (!KernelIs64BitOnly) {@@ -767,6 +766,7 @@       AddMenuCheck(SubScreen, "macOS 64bit",          OPT_X64,  68);   ...

#2447504 [pre-release] macOS High Sierra

Posted by RehabMan on 19 June 2017 - 04:42 PM

 What do I need to do in order to run "native" kbl kexts? Like, what adjustments from the normal way of doing things with kext(like the ones you've made). I have Kaby Lake 7700HQ on dell xps 15. Typical setup:- config.plist/Inject/Intel=true- config.plist/ig-platform-id set to valid ig-platform-id for KabyLake.  My process was on a desktop, so I used 0x59120000.  Laptops would be different.- config.plist/Devices/FakeID/IntelGFX=0- as mentioned, kernel flag -disablegfxfirmware (if you get the problem with firmware load)- Lilu.kext + IntelGraphicsFixup.kext probably needed (latest versions)- DVMT-prealloc set to 64mb or larger (or use patch ig-platform-id data as required for 32mb)- no need for FakePCIID_Intel_HD_Graphics.kext, but if you install it in this scenario... it won't do anything (it doesn't load with native KBL device-id) Extracted ig-platform-id values from AppleIntelKBLGraphicsFramebuffer.kext.... ig-platform-id values KBL 10.13.dp1 00 0...

#2447474 [pre-release] macOS High Sierra

Posted by RehabMan on 19 June 2017 - 03:45 PM

For anyone that runs into the endless "Begin Gfx firmware load process"... "Hash data from ME never returned", when attempting to use native KBL kexts with Kaby Lake integrated graphics...You can add kernel flag "-disablegfxfirmware" to config.plist/Boot/Arguments to skip the firmware load code.Probably same thing with 10.12.6 native KBL kexts, but I only tested on 10.13.dp1.

#2447382 Clover General discussion

Posted by RehabMan on 19 June 2017 - 02:07 PM

if (Prop && IsPropertyTrue (Prop)) {+ gSettings.HWP = TRUE;+ AsmWriteMsr64 (MSR_IA32_PM_ENABLE, 1);+ }Here is the code for turning HWP on for Clover. But it became ineffective when computer waked up from sleep. Is there a way we can manually call this method so that HWP remains effective after sleep?  No need for that option at all...For correct HWP implementation, use an SMBIOS that has HWP enabled or edit the plist in X86PlatformPlugin.kext/Resources appropriately.HWP will be enabled on boot and on wake from sleep with correct SMBIOS/X86PlatformPlugin setup.

#2434112 Patch for using NVMe under macOS Sierra is ready.

Posted by RehabMan on 02 June 2017 - 12:47 PM

In the meantime, it works under MacOS. I just edited config.plist with the code lines, no need to use the hack. I don't understand why, but it's working. KextsToPatch is effective.  But a bit dangerous...  First, you have to be certain you have the correct patches for the version of IONVMeFamily you have.  And in the case of an update, you must be sure you have both the set of patches for the current version as well as the updated version, selected via MatchOS or MatchBuild.  It can get tricky.

#2433710 Patch for using NVMe under macOS Sierra is ready.

Posted by RehabMan on 01 June 2017 - 02:26 PM

Just a general question. Im using a Corsiar MP500 250GB NVMe drive. I use the HackrNvmeFamily.kext in Clover/kexts/10.12 and also use the SSDT-NVMe-Pcc.aml in clover patched. All plist patches in kext to patch are removed and NVMe works flawless as internal as usual. "I dont use the _DSM-XDSM patch due to using a custom DSDT in clover patched" Anyways usual write and read speeds are 1239mb write and 2253read but from time to time my write speeds will fall all the way down to 200mb write speeds. And they will stay there for a minute or so. Then back up to normal speeds. Is this normal? Or is there something im doing wrong somewhere?  Normal.  Probably throttling due to heat issues, or just the SSD firmware catching up with requests.

#2430051 Patch for using NVMe under macOS Sierra is ready.

Posted by RehabMan on 24 May 2017 - 01:51 AM

Please Help-me to fix this. Obs:. Sorry for my bad english. Suggest you read the guide carefully, and stick only to what is written... (you have some additions in your SSDT that are not part of the guide... and wrong).

#2429336 Clover General discussion

Posted by RehabMan on 22 May 2017 - 01:40 PM

As well there is no need to keep MatchOS and MatchBuild. Just make patch search to be unique. MatchOS and MatchBuild are very useful features.

#2429049 Clover General discussion

Posted by RehabMan on 21 May 2017 - 07:52 PM

@RehabMan:Any chance of incorporating the patches of IntelGraphicsFixup.kext into a Clover patch? I probably won't look at doing that until I have hardware that demonstrates the problem.So far, I don't have any HD520/HD530/HD620/HD630 hardware.
  • nms likes this

#2427626 Clover General discussion

Posted by RehabMan on 19 May 2017 - 09:35 PM

@RehabMan - i really agree the frame buffer patch method is better than patch the assertion.Bravo to you for cracking the code for us lap-toppers with immutable bios!!! @sherlocks- i figured out why the DVMTFixup 1.1.3 was not working.- not a problem with Lilu- need change your patch count for each pattern Unlike, the old method which is a patch to avoid assertion, RehabMan's new buffer patches have more that 1 occurrence. so here is an example : changed number 1 to 7 matches for 01030303 00002002 00005001                     const uint8_t find2[]   = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x20, 0x02, 0x00, 0x00, 0x50, 0x01};   const uint8_t replace2[] = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x30, 0x01, 0x00, 0x00, 0x90, 0x00};   KextPatch kext_patch2 {   {&kextList, find2, replace2, sizeof(find2), 7},   KernelVersion::ElCapitan, KernelVersion::Si...

© 2016 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy