Jump to content
30960 posts in this topic

Recommended Posts

Post the diff patch here, for review.

Here you go: 

Index: rEFIt_UEFI/refit/main.c
===================================================================
--- rEFIt_UEFI/refit/main.c	(revision 4414)
+++ rEFIt_UEFI/refit/main.c	(working copy)
@@ -1881,6 +1881,7 @@
   BOOLEAN           MainLoopRunning = TRUE;
   BOOLEAN           ReinitDesktop = TRUE;
   BOOLEAN           AfterTool = FALSE;
+    BOOLEAN           KeyPressedForGUI = FALSE;
   REFIT_MENU_ENTRY  *ChosenEntry = NULL;
   REFIT_MENU_ENTRY  *DefaultEntry = NULL;
   REFIT_MENU_ENTRY  *OptionEntry = NULL;
@@ -2123,7 +2124,7 @@
 #endif // ENABLE_SECURE_BOOT
 
   MainMenu.TimeoutSeconds = GlobalConfig.Timeout >= 0 ? GlobalConfig.Timeout : 0;
-
+    KeyPressedForGUI=ReadAllKeyStrokes();
   //DBG("LoadDrivers() start\n");
   LoadDrivers();
   //DBG("LoadDrivers() end\n");
@@ -2468,7 +2469,7 @@
     gEvent = 0; //clear to cancel loop
     while (MainLoopRunning) {
       CHAR8 *LastChosenOS = NULL;
-      if (GlobalConfig.Timeout == 0 && DefaultEntry != NULL && !ReadAllKeyStrokes()) {
+      if (GlobalConfig.Timeout == 0 && DefaultEntry != NULL && !ReadAllKeyStrokes()&&!KeyPressedForGUI) {
         // go strait to DefaultVolume loading
         MenuExit = MENU_EXIT_TIMEOUT;
       } else {

This just discards any keystrokes that should have been intercepted by either the apple input protocols or the GUI. Instead, after LoadDrivers(), KeyPressedForGUI should be TRUE only after locating the apple key aggregator protocol, and inspecting whether there is any key information present.

This just discards any keystrokes that should have been intercepted by either the apple input protocols or the GUI. Instead, after LoadDrivers(), KeyPressedForGUI should be TRUE only after locating the apple key aggregator protocol, and inspecting whether there is any key information present.

Just wonder why the AptioInputFix doesn't affect when the GUI Loaded?

I put the ReadAllKeyStrokes there to prevent AptioInputFix some kind of override the key that use to enter GUI from timeout=0

IntelCPUMonitor isn't a part of the OS, it's part of HWSensors 3.

 

Its a fresh install without HWSensors added by me.   I loaded HS 13.3 from scratch then updated to beta 13.4.    It works fine on the first boot but after a reboot it gets this error.    

It might be in your ESP.

I erased the drive before the install. But I will try again, so far it has happened on a fresh install and two other drives that were updated from 13.2-13.3 to 13.4. There is also another user with the same error on an FX and a Ryzen system initial boot is fine but the restart gets the error.

 

My research mentioned fakesmckext and HWSensirs plug-ins but I’m not using those for my AMD setup. In fact I removed the fakesmckext from clover. It’s a long boot without it.

I erased the drive before the install. But I will try again, so far it has happened on a fresh install and two other drives that were updated from 13.2-13.3 to 13.4. There is also another user with the same error on an FX and a Ryzen system initial boot is fine but the restart gets the error.

 

My research mentioned fakesmckext and HWSensirs plug-ins but I’m not using those for my AMD setup. In fact I removed the fakesmckext from clover. It’s a long boot without it.

Make sure to check inside fakesmc.kext also, sometimes there are plugins inside it.

  • Like 1

I erased the drive before the install. But I will try again, so far it has happened on a fresh install and two other drives that were updated from 13.2-13.3 to 13.4. There is also another user with the same error on an FX and a Ryzen system initial boot is fine but the restart gets the error.

 

My research mentioned fakesmckext and HWSensirs plug-ins but I’m not using those for my AMD setup. In fact I removed the fakesmckext from clover. It’s a long boot without it.

After the first boot, the kext gets into the prelinked kernel and fails to load for second boot.

  • Like 1

After the first boot, the kext gets into the prelinked kernel and fails to load for second boot.

 

I've replaced the prelinked kernel a few times but it still doesn't remove the error I will do another fresh install and save all my kernels and relinked kernels for more testing.    I will not add fakesmckext and or check it for plugins.  It makes for a long boot (timeout 60 sec,.) over and over again. 

run kextcache with "-v 3" switch.  It will tell you each kext prelinked.

 

I ran a kextstat command earlier and it showed HWSensors loaded but I didn't install them.    It only happens in 13.4 with 13.3 I never have this issue.   I wonder if apple has incorporated HW sensors in the beta 13.4 like they did with whatevergreen and/or Rad de init for AMD graphics?

 

Thanks everyone for the replies I will continue to search this out and check all suggestions.

@Gigamax

There are two versions of HWSensors, kozleks/rehabman(HwSensors+FakeSMC6) and my (HWSensors3+FakeSMC3.5). Only my version is intended for AMD CPU.

If first one then open FakeSMC/Contens/Plugins and look inside.

If my version then IntelCPUMonitor can be in EFI/CLOVER/kexts/other folder or in /System/Library/Extensions. In the second case you have to delete kext and /System/Library/Prelinkedkernels/prelinkedkernel

  • Like 1

Oh man, that's cool, what are the last two combinations? CMD+R worked? How would that work if say your selected boot volume was corrupted and couldn't be read? Does it search for any other boot.efi and let it find the recovery? That's weird, so it probably does.... lol.

vit said this in FileVault 2 post:

 

 

Modified UsbKbDxe, a slightly altered version is present in Clover.

Pros:

— works with any USB keyboard in any BIOS;

— offers completely functional Apple boot keys (CMD+V, 3+2, CMD+R, etc.);

Cons:

— might require a physical keyboard reconnect after driver load with AMI UEFI BIOS;

— might lead to a complete freeze of the system with AMI UEFI BIOS.

just found this: http://www.insanelymac.com/forum/topic/331381-aptiomemoryfix/?p=2572819

so I think it is handled somehow by boot.efi?

new okrasit patches for EIST for 10.13.4 beta (performance fix if EIST is enabled in bios)

 

All credits goes to PMHeart which discovered new kernel locations  :)

 

Thank you

 

in kernel section

find
C1E30848 63D389D0 48C1EA20 B9990100 000F3048 FF05C940 6E004883 C4085B5D C3662E0F 1F840000 000000

 

repl
BB00FF00 004863D3 89D048C1 EA20B999 0100000F 3048FF05 C9406E00 4883C408 5B5DC390 90909090 909090

So, I by mistake pressed F9 key on Clover GUI. Soon, I got black screen with a blinking cursor on the top left.

Then, I press Esc key and the GUI appears again but it uses my lowest disp reso (Vesa 640x480. Custom set was 1360x768).

My question; What is F9 key for? I see nothing on Help menu. Thanks.

(FYi, I'm using Legacy Clover r4414).

 

 

Mx2pmPS.png

 

Hi,

 

I just found out that since 10.9 you do not use a cpu timing SSDT anymore and enable PluginType in Clover's ACPI settings instead. Honestly I did not get that from reading the clover documentation only.... So it generates this powermanagement SSDT, right?:

 

 

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20161210-64(RM)
 * Copyright (c) 2000 - 2016 Intel Corporation
 * 
 * Disassembling to non-symbolic legacy ASL operators
 *
 * Disassembly of iASL6V44Zi.aml, Mon Feb 12 13:55:10 2018
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x00000053 (83)
 *     Revision         0x01
 *     Checksum         0x80
 *     OEM ID           "PmRef"
 *     OEM Table ID     "CpuPm"
 *     OEM Revision     0x00003000 (12288)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20120320 (538051360)
 */
DefinitionBlock ("", "SSDT", 1, "PmRef", "CpuPm", 0x00003000)
{
    External (_PR_.CPU0, DeviceObj)    // Warning: Unknown object

    Scope (\_PR.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                     0x03                                           
                })
            }

            Return (Package (0x02)
            {
                "plugin-type", 
                One
            })
        }
    }
}

 

 

 

 

Now XCPM is really enabled, and everything feels a tiny bit more snappy. Now PikerAlpha stated in his original blog post, that also AppleSMBusPCI.kext is not required anymore - but it stills loads here. Any idea why it loads? I can unload it, without any change.

 

Also another related question: The guide says not to activate "dropOEM". But do I still have to drop my vendors Cpu0Ist and CpuPm ssdts?

Just wonder why the AptioInputFix doesn't affect when the GUI Loaded?

I put the ReadAllKeyStrokes there to prevent AptioInputFix some kind of override the key that use to enter GUI from timeout=0

 

It does. That's why you can't press a key and get into the GUI, because the key aggregator ate all the previous key strokes. The code you gave just discards them instead of using them in the aggregator or the GUI properly. Locate the key aggregator proctocol and check that it has any keys in it's buffer, if you really want to be thorough only set KeyPressedForGUI if the keystrokes in the key aggregator are not relevant to a startup command.

 

vit said this in FileVault 2 post:

just found this: http://www.insanelymac.com/forum/topic/331381-aptiomemoryfix/?p=2572819

so I think it is handled somehow by boot.efi?

 

Yes, some are handled by boot.efi, by the firmware gathering keystrokes into the key aggregator and that is examined by boot.efi. So if you read all the keystrokes before the driver is loaded then you discarded them before the driver could gather them. So you've exchanged the functionality of the key aggregator before boot for the functionality of the GUI appearing, they should not be mutually exclusive.

 

I will not add fakesmckext and or check it for plugins.

 

You cannot boot without FakeSMC.... Also almost guarantee you are just copying FakeSMC.kext straight from the download and not removing any of it's plugins, which is where the monitor is usually.

 

new okrasit patches for EIST for 10.13.4 beta (performance fix if EIST is enabled in bios)

 

All credits goes to PMHeart which discovered new kernel locations  :)

 

Thank you

 

in kernel section

find

C1E30848 63D389D0 48C1EA20 B9990100 000F3048 FF05C940 6E004883 C4085B5D C3662E0F 1F840000 000000

 

repl

BB00FF00 004863D3 89D048C1 EA20B999 0100000F 3048FF05 C9406E00 4883C408 5B5DC390 90909090 909090

 

EIST is speedstep..... Why would speedstep be causing issues? Who is not enabling speed step? WTF is this post about?

 

So, I by mistake pressed F9 key on Clover GUI. Soon, I got black screen with a blinking cursor on the top left.

Then, I press Esc key and the GUI appears again but it uses my lowest disp reso (Vesa 640x480. Custom set was 1360x768).

My question; What is F9 key for? I see nothing on Help menu. Thanks.

(FYi, I'm using Legacy Clover r4414).

 

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/refit/menu.c#l2535

 

Hi,

 

I just found out that since 10.9 you do not use a cpu timing SSDT anymore and enable PluginType in Clover's ACPI settings instead. Honestly I did not get that from reading the clover documentation only.... So it generates this powermanagement SSDT, right?:

 

Now XCPM is really enabled, and everything feels a tiny bit more snappy. Now PikerAlpha stated in his original blog post, that also AppleSMBusPCI.kext is not required anymore - but it stills loads here. Any idea why it loads? I can unload it, without any change.

 

Also another related question: The guide says not to active "dropOEM". But do I still have to drop my vendors Cpu0Ist and CpuPm ssdts?

 

If you have a table named CpuPm or that already defines any of those methods you cannot inject that table or it will just be discarded. You don't need an speedstep SSDT for XCPM because the state data is stored elsewhere in OS resources. Most likely you don't want to drop those tables, especially CpuPm if you are going to be using them. So you'll probably have to edit your CpuPm table anyway because of the name and it probably most likely already has a _DSM method, so maybe just edit that and add that code to it?

  • Like 2

Hi apianti

I don't like your way to express here  (WTF) but I will try to explain in a kind way I hope

 

Do you know what okrasit patch does in case of an unsupported CPU if you have bios EIST function enabled?

 

It helps to reach in that case Higher states for cpu during loaded task 

to explain better

EIST enabled no turboboost for (unsupported) CPU

ie cinebench15 benchmark in my rig has a correct value of 2950 with EIST disable and 2450 with EIST enabled and without this patch

 

I would like also to remember you in some old clover release this patch (or similar was included) if I don't remember bad

 

 

 

 

 

EIST is speedstep..... Why would speedstep be causing issues? Who is not enabling speed step? WTF is this post about?

 

 

It does. That's why you can't press a key and get into the GUI, because the key aggregator ate all the previous key strokes. The code you gave just discards them instead of using them in the aggregator or the GUI properly. Locate the key aggregator proctocol and check that it has any keys in it's buffer, if you really want to be thorough only set KeyPressedForGUI if the keystrokes in the key aggregator are not relevant to a startup command.

 

 

Yes, some are handled by boot.efi, by the firmware gathering keystrokes into the key aggregator and that is examined by boot.efi. So if you read all the keystrokes before the driver is loaded then you discarded them before the driver could gather them. So you've exchanged the functionality of the key aggregator before boot for the functionality of the GUI appearing, they should not be mutually exclusive.

So if I clear all ReadAllKeyStrokes in the code, I will get the apple boot function key combo?

Hi apianti

I don't like your way to express here  (WTF) but I will try to explain in a kind way I hope

 

Do you know what okrasit patch does in case of an unsupported CPU if you have bios EIST function enabled?

 

It helps to reach in that case Higher states for cpu during loaded task 

to explain better

EIST enabled no turboboost for (unsupported) CPU

ie cinebench15 benchmark in my rig has a correct value of 2950 with EIST disable and 2450 with EIST enabled and without this patch

 

I would like also to remember you in some old clover release this patch (or similar was included) if I don't remember bad

 

Turbo boost and EIST are completely unrelated and can be independently enabled/disabled. You can have speedstep but not turbo, turbo but not speed step. And turbo is not getting you 500 more benchmark points. You still did not explain what this patch DOES. Is this just for unsupported CPUs??

 

EDIT: It seems to me from your explanation that you got back your 2950 score when your CPU wasn't using EIST, so in essence this is just disabling EIST for full speed? Because that's why your score was higher without it, there was no caring about power usage, so it was just beasting through. If EIST is enabled, then it will reduce frequency when it reaches a thermal threshold to lower power consumption.

 

So if I clear all ReadAllKeyStrokes in the code, I will get the apple boot function key combo?

 

Oh god, no. I told you how to properly determine if there is a key stroke, inspect the key aggregator protocol.

apianti, in OSX with EIST enabled in bios my and I think many other unsupported cpu do not reach higher turbo boost states

Okrasit time ago found this patches with (I think but I am not a guru like you) disable EIST

so in case you have windows and OSX you can Have EIST enabled in bios and then patch it via clover in OSX

 

I can't explain better

;)

 

Turbo boost and EIST are completely unrelated and can be independently enabled/disabled. You can have speedstep but not turbo, turbo but not speed step. And turbo is not getting you 500 more benchmark points. You still did not explain what this patch DOES. Is this just for unsupported CPUs??

 

 

Oh god, no. I told you how to properly determine if there is a key stroke, inspect the key aggregator protocol.

apianti, in OSX with EIST enabled in bios my and I think many other unsupported cpu do not reach higher turbo boost states

Okrasit time ago found this patches with (I think but I am not a guru like you) disable EIST

so in case you have windows and OSX you can Have EIST enabled in bios and then patch it via clover in OSX

 

I can't explain better

;)

 

Yes, so as I said this patch is disabling speedstep, which is equivalent to NullCpuPowerManagement.kext, which is terrible and causes your CPU to run full speed all the time. Maybe a better solution would be to edit the p state data for the SMBIOS you are trying to use so that it reaches more and higher states since they are setup for the CPU models apple uses???

×
×
  • Create New...