Jump to content


  • Content Count

  • Joined

  • Last visited

About interferenc

  • Rank
    InsanelyMac Protégé

Recent Profile Visitors

319 profile views
  1. if plugin type 1 is set, osx will load X86PlatformPlugin.kext. If plugin type 1 is not set, osx will load ACPI_SMC_PlatformPlugin.kext
  2. hey guys, I also got notified about the patches being included in UEFIPatch, and saw that they are the older patches and also lack the patch that fixes the e3 wake issue. I submitted a pull request here: https://github.com/LongSoft/UEFITool/pull/113 The other issue is a minor one, where patching the same GUID more than once does not work properly. Sadly that's still true, but on the upside, we don't really need that. https://github.com/LongSoft/UEFITool/issues/92 Also, while I am really satisfied with my TSC patches, that addresses a different issue than the MSR unlock, so while the patch is useful, I am not sure that should be in the official UEFIPatch distribution. Thus I only submitted the unlocking patches. I have gist here with the TSC patches included for Asus boards if anybody needs it, I know it is kgp's guide as well: https://gist.github.com/interferenc/d82357a13751bc24dcc5942f6af2374b
  3. Oh yes I missed that. About the usefulness: If you have MSR 0xE2 locked, you need these three patches an Asus boards: https://gist.github.com/interferenc/713e48b40735b2dbc15977bec4013d24 If you have Unsynced TSCs, you need a fix of some kind. We resorted to VoodooTSCSync, but I tried to sync the TSCs on boot and wake by using the location of the MSR 0xE2 locking asm code, nopping it out and then inserting a simple wrmsr(IA32_TSC_ADJUST, 0) instruction. This also needs to happen at two places, one for boot (pmpInitialize) and on wake (CpuInitPei). The third patch is just an occurence of the bios writing to the tsc (CpuMpDxe), and as that is something that we do not want in any case, I disabled it in any case. https://gist.github.com/interferenc/d82357a13751bc24dcc5942f6af2374b So thats it. If you have an unlocked board, the patches do not apply. If you have a different board with a bios that locks the registers in a different way/place, the patches do not apply. For those boards, alternative patches should be made.
  4. Sadly I am not familiar with all the different container types these bios capsule files use. UEFIPatch should be able to patch anything sooner or later, for example they added ffsv3 support when it was needed. If you have problems patching some of the GUIDs then file an issue at github and I think they will sort it out. I also have problems patching the same GUID more then one in the same run, that does not work, but patching in two rounds do work. So, thats all I know about UEFIPatch, sorry. As a last resort, you can patch manually be extracting the body, editing with a hex editor, and then replacing the body.
  5. Okay so let's continue the discussion here. @kgp Yes, clover can put the plugin type into the first cpu with that option you selected in clover configurator. Personally I prefer to edit my own SSDTs, but it should have the same effect.
  6. interferenc

    [UEFIPatch] UEFI patching utility

    Just some heads up: took me a day but I finally found it: there are THREE places where the cfg lock is enforced. Patches are here: https://gist.github.com/interferenc/713e48b40735b2dbc15977bec4013d24
  7. interferenc

    [UEFIPatch] UEFI patching utility

    Hey guys, I am working on a patch for x299. This patch applies, but it is not enough # SiInit | Kaby Lake 299D6F8B-2EC9-4E40-9EC6-DDAA7EBF5FD9 10 P:81E10080000033C1:9090909090909090 This patch I made IS enough: # PpmInitialize | Skylake X 3FFCAE95-23CF-4967-94F5-16352F68E43B 10 P:0FBAE80F:0FBAE00F But for some strange reason the msr 0xe2 is re-locken on s3 resume. Any idea why? Has anybody ever seen that happen? Thanks.
  8. interferenc

    Clover General discussion

    Hey, I am trying to find our why I need VoodooTSCSycn on my x299 system. I am comparing my published efi platform data to one from a a real iMacPro. The obvious differences are (other keys are removed for clarity): iMacPro | +-o platform <class IOService, id 0x100000113, !registered, !matched, active, busy 0, retain 7> | { | "board-rev" = <09> | "InitialTSC" = <26486eee7a2a0000> | "apple-coprocessor-version" = <00000200> | "FSBFrequency" = <00105e5f00000000> | "board-id" = <"Mac-7BA5B2D9E42DDD94"> | } My x299 hack | +-o platform <class IOService, id 0x100000113, !registered, !matched, active, busy 0, retain 9> | { | "CPUFrequency" = <40e6a2d600000000> | "FSBFrequency" = <6717f60500000000> | "InitialTSC" = <984a9bd600000000> | } So iMacPro has a board-rev and board-id property, but I don't think that matters here. More interestingly, there is no CPUFrequency on the real mac, and that key is not referenced anywhere in the kernel or boot.efi. So while this is a difference, it probably does not matter (i can boot without one). The FSBFrequency on the iMacPro is 1600Mhz, like if it was multiplied by the logical core count(16*100Mhz). In the kernel, FSBFrquency is not used for skylake cpu family, but there is a reference in boot.efi, so it might matter. And the most interesting, the InitialTSC value is 3600501400Hz for my system, and that is probably correct. However, this field on the iMacPro looks like it should not contain the TSC frequency, but the intital tsc tick value, something like you can read by rdtsc64(). This value is read by the kernel to tsc_at_boot and then used like this in one point: if (tsc_rebase_abs_time == 0) tsc_rebase_abs_time = _rtc_tsc_to_nanoseconds(rdtsc64() - tsc_at_boot, rntp); Which makes it clear that this value should indeed be a tick number, not a frequency value. At another point, tsc_at_boot is stored in sysctl like this: SYSCTL_QUAD(_machdep_tsc, OID_AUTO, at_boot, CTLFLAG_RD|CTLFLAG_LOCKED, &tsc_at_boot, ""); That variable on my system after boot is: machdep.tsc.at_boot: 0 Which is interesting, as it is set on efi/platform, but somehow ends up being 0. So my questions are: Why is the FSBFrequency 1600Mhz on the iMacPro? Does it even matter? Is the InitialTSC value calculated by clover properly? The use of this value by the kernel indicates it is not.
  9. interferenc


    So I am getting a message that some slide values are not available and boot might fail. But it does not. Is this something to worry about?