Hibernation Fix

[tylernguyen]

Currently. it is recommended to disable hibernation to avoid problems. However, with all the time suddenly on my hand. It seems about time to try and figure out hibernation mode 25 on x1c6-hackintosh.
The biggest benefit from hibernation mode 25 would be saving power for users to who often put their x1c6 to sleep for semi-long periods of time, like me.
I hope that hibernation mode 25 will work. Even if not, I want to be get to the end of this issue.
Updates soon in the coming two weeks. Meanwhile, if anyone knows anything, feel free to chime in.

[tylernguyen]

Small update:

• Hibernate mode 3 seems to function, though extended testing is needed.
  It seems that hibernate mode 25 will trigger CMOS error upon entering sleep. Though I am not sure if this is due to my own CMOS battery. An additional tester is needed, please lmk.

[Ranguvar]

S3 sleep is working well for me (hibernate = 3).
Achieved kernel panic after macOS tried to change from sleep to hibernate once, attached.
Now changed standby to 0 so hibernate is disabled, no more panics yet.
panic-hibernate-1.txt

[tylernguyen]

@Ranguvar Could you try setting hibernate mode to 25 and see what happens on your machine?

[duylenfq]

Hi @tylernguyen I've been using your guide for 1 day, just finished on my X1C and noticed that the computer didn't sleep on LID closed or Apple --> Sleep as well. Because when I open the lid, it almost screened up instantly and the plate is warm, I also lost 25% in 1hr of sleep and LED light won't blink but constantly on. That was during the hibernation = 0.
Now I just changed to 3 hope it would make a difference :(

[tylernguyen]

@duylenfq

Please run pmset -g log | grep -e "Wake.*due to " to see what's preventing your laptop from sleeping.

Also, please read and check against this guide

[duylenfq]

I did check the guide, so far this is what it returned

Just to clarify I remapped USB correctly under Hackintool and during sleep nothing attached via USB externally...

[Ranguvar]

@Ranguvar Could you try setting hibernate mode to 25 and see what happens on your machine?

Leave standby 0 or 1?

[Ranguvar]

With hibernatremode on 25 and standby on 1, I left my laptop alone.
When I came back to it, I do not recall if it was off or if the LED was pulsing, but it booted to the BIOS splash screen.

I had an error display, 0251: System CMOS Checksum bad - Default configuration used.

macOS did then fail to boot once, but I don't have the log. It is working again now.

[Ranguvar]

With hibernatemode on 25 and standby on 0, it seems I got the normal sleep I did with hibernate mode on 3?

[tylernguyen]

I did check the guide, so far this is what it returned

Just to clarify I remapped USB correctly under Hackintool and during sleep nothing attached via USB externally...

@duylenfq You need to turn Power Nap off. I'll update this in the 5_README-other so others can see.

With hibernatemode on 25 and standby on 0, it seems I got the normal sleep I did with hibernate mode on 3?

@Ranguvar Can you do an extended test and confirm power drainage with hibernatenmode=25?

[duylenfq]

hi @tylernguyen I didn't have Power nap enabled, it was disabled from day 1

I will also try hibernatemode=25 and see if it works on my machine

Since I am using intel wifi, I disable USB map for bluetooth as well, hope this will returns good result.

In the meanwhile, the LED light is not still blinking, constantly on no matter what....

[tylernguyen]

@duylenfq

Make sure you don't have powernap enabled for the power adapter either. Also, how are you using intel wifi? which kext are you using? What's your machine model?

In addition, what's your bios settings? Is wake-on-lan disabled?

Are there any USB devices connected during sleep?

Please check pmset -g assertions and clear power assertions to default.

Btw, Hackintool is not good for mapping USB ports, it uses an outdated version of USBMap. It's better for you just to use USBMap directly instead.

[duylenfq]

@tylernguyen my model is exactly as yours with identical specs, except my wifi card is not replaced yet (waiting for DW1560 to be shipped. Some details below:
info.txt
Bios is also exactly as your guide, I disabled wake on LAN and dock to be sure, WWAN also disabled along with SD card reader. When I tested the sleep, just click on Sleep and leave the laptop alone, nothing connected to it.
I remapped USB accordingly to USBMap as well, nothing changed yet....

I did a double check AHCI mapping and I have the same rooting as yours, SB.PCI0.LPCB.EC
Edit1: My wifi kext is from here: https://www.tonymacx86.com/threads/success-working-intel-wifi-drivers-for-7265ac-on-catalina.292207/page-14 https://www.tonymacx86.com/attachments/appleintelwifi-kext-catalina-zip.450679/
Edit2: try removing AHCI patching and left only the basic (kexts unchanged) didn't seem to help with sleep.... Kinda make a compromise to live with it as of now ...
Edit 3: found this, checking why....

[Ranguvar]

I just had the machine stay sleeping and it required a reboot when trying to resume, using standby 0 and hibernatemode 25.

I did also have Power Nap on, as I was plugged into an AC adapter this time, though.

Not sure how to run an extended test other than recording battery percentages before/after sleep of say 1hr?

So far hibernatemode 25 is either as good as or better than 3 with standby 0 and Power Nap off, I can't be sure yet.

[tylernguyen]

@duylenfq from the first output, HID activity is usually an issue from USB mapping, what power injection did you use?

Please clear NVRAM and check if it works. Also, please upload a zip of your EFI with SMBIOS info removed. I will inspect your EFI and try to guess what's wrong. But so, I would recommend you do a fresh install and test sleep before installing any 3rd-party apps or tools.

Sleep was never an issue with this project, I suspect it maybe caused by the Intel WiFi kext, since it is really the only thing different from our two machines (I recommend against intel wifi currently anyway because it's very buggy and incomplete.)

@Ranguvar
Power nap causes problems. I recommend you disable it on both power and battery.
And yes, there's really no other tests than just charging it to 100%, setting hibernatemode to 3 or 25, let it drain for hours, then comparing the two results.

Be sure to record your pmset -g settings as you set them.

For now, I suggest you keep standby constant and only change hibernatemode when testing.
Also, how did you avoid CMOS error with hibernatemode 25, I keep running into it whenever I tried.

[duylenfq]

hi @tylernguyen I have some updates:

• Fresh installed x2 with wifi card replaced by DW 1560, not really helped for sleep problem. I also tried disabling all USB port see if it works and I have the HID issue:

• I also checked my USB setup (I mapped 5 times just to make sure I didn't miss anything) and status = good, however sleep problem not fixed

- I uploaded my EFI here: https://drive.google.com/file/d/1xykAurpOjnWxYVJ58Ebq-sb_7ICGcgLd/view?usp=sharing - I see 2 other problems not sure related here though: When I do combo Shift+Fn (Ctrl key)+4 = dark screen, cannot wake I had to power reset. HDMI not working as well even my GPU acceleration works well (plugged in both usb C and HDMI port, no output, sometimes laptop screen went dark as well, cannot wake). - My DSDT here: https://drive.google.com/file/d/1-ozojBnx9UWR1bkBPVSyyex4CYVcKkXM/view?usp=sharing, just in case...

--> The sleep problem is not as annoying as [HDMI port not working at all + dark screen on mistaken combo key to screenshot] This drives me crazy when I need to work and present a screen. Spent more than 1 week on this now :( if you could help I would gladly donate for your great work thus far.
Thank you in advance.

[tylernguyen]

@duylenfq
I've just taken a look at your EFI. Some comments:

• SSDT-UIAC is meant to be used with USBInjectAll

• USBMap does the same thing as SSDT-UIAC and USBInjectAll
  These two setups are mutually exclusive, either SSDT-UIAC and USBInjectAll or USBMap, not both.

• Similarly, SSDT-PNLF and SSDT-PNLF-SKL_KBL do the same thing, use one only.

• SSDT-EXT* are all extensions of SSDT-PTSWAK, so SSDT-PTSWAK needs to be loaded first in OpenCore config.plist

Please read my ACPI doc: https://github.com/tylernguyen/x1c6-hackintosh/blob/master/docs/4_README-ACPIpatching.md

Specifically, please pay attention to the SSDT-PTSWAK section and confirm your own _WAK and _PTS properties in source DSDT. Yours may be different from mine.

• Is there a specific reason for you to use SMBIOS 14,3? 14,1 is a better SMBIOS for compatibility and it's the SMBIOS that my project is designed around. I suggest you switch to 14,1

• You are injecting AppleALC layout-id twice, one in devices and another time in boot arguments. Please inject only in 1 place.

• I see that you you have VoodooI2C installed, do you have a touchscreen?

• SSDT-GPI0 is also installed, this patch is meant for I2C touchpad. As far as I know, x1c6 do not have touchpads unless installed aftermarket?

• Similarly, x1c6 do not have an ambient light sensor so you can remove SMCLightSensor

• WhateverGreen is loaded too late in config.plist. Load it earlier, but after Lilu.

• Again, you are loading VoodooInput twice, one with VoodooI2C, and another time with VoodooPS2, please only use one.

• You are using BuiltIn BootPicker, so there's no need for OpenCanopy.efi and the Resources folder.

• If you do not have a touchscreen or a known I2C device, please remove the package entirely, I suspect that this might be causing your sleep problems.

But overall, please take a look at all my comments and clean your setup. It seems very messy.

It seems like this config.plist was made from scratch, is there a reason for you to do so? I think a better approach would be starting off with my Opencore-EFI. After that, you can add the things you need, be it touchscreen, WiFi

[duylenfq]

Thanks @tylernguyen for the response and check. Due to the instability of the OS so far, mostly with sleep and HDMI totally unusable I set it aside (for now) and back to Windows to be able to work and collaborate with my colleagues. I did a check as you said + another attempt on using your exact folders (except changed platform info, CPU friend, and USBinjectall). So far it only costs time and effort, although I could use the machine just with the internal display, without HDMI it's a deal-breaker for me though.....

I think as of now just for my case, the OS is far less stable compared to my hack desktop, I will stick to it for awhile....

[benbender]

@tylernguyen I've briefly tried to make hibernatemode 25 work and it did - but resulted in the same CMOS-error you observed. I did it out of curiosity while beeing happy with mode 3.

I think the problem we are facing is takled by the following kext, butI didn't try to debug my RTC-Banks to make it work. If you are interested: https://github.com/acidanthera/RTCMemoryFixup

[benbender]

Just stumbled upon this issue which may be related: acidanthera/bugtracker#765

[tylernguyen]

@benbender Thanks for bringing this to my attention. I will look into that issue and continue testing hibernate mode 25.

[tylernguyen]

@benbender With the fixes on that issue applied, I'm still getting CMOS error. Could you confirm that behavior? It seems that we would need to create our own exclusions after all.

[benbender]

I didn't investigate yet, but plan to do so because there seems to be more functionality depending on working RTC/CMOS. The important information for me are a) there are changes from 10.15.4 onwards and b) there are new options in OC 0.5.9 to handle it. Rest is object to fiddling around.

Important first question is size and correctness of our RTC-ACPI-definition.

To get started, some questions to clearify:

a) my RTC-Definition (stock ACPI, latest Bios) - same for you?

        Device (RTC)
        {
            Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0070,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {8}
            })
        }

b) I had messages in the past that I have only 128bytes of RTC-Memory. We need to confirm if this is correct?

c) I didn't find any informations about this IRQ-TIMR-RTC-patches and if they are needed or not (besides "something" with the audio-devices). Do you have any informations about the purpose of that patch and if its needed on x1c6/t480/t480s?

[tylernguyen]

@benbender
a) My RTC definition seems identical to yours:

  Device (RTC)
        {
            Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0070,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {8}
            })
        }

b) How would we confirm that?
c) Regarding IRQ, this is standard assignments:

IRQ 0 | System Timer (CMOS)
IRQ 1 | Keyboard
IRQ 2 | Cascaded with IRQ 9
IRQ 3 | Default COM2 and COM4
IRQ 4 | Default COM1 and COM3
IRQ 5 | LPT2
IRQ 6 | Floppy Drive Controller
IRQ 7 | LPT1
IRQ 8 | Real Time Clock
IRQ 9 | SEE 2
IRQ 10 | Open
IRQ 11 | Open
IRQ 12 | PS/2 mouse or Open
IRQ 13 | Math Coprocessor
IRQ 14 | Primary Hard Drive controller
IRQ 15 | Secondary Hard Drive controller

If someone still has Windows, could confirm this in Device Manager? Lenovo may have custom IRQ assignments.

TIMR should be one that's related to sound, that patch is not needed as far as I know and is really for legacy hardware.

RTC likely our culprit for our hibernation error. Just as we previous suspected, it is likely some conflicts with AppleRTC our own, and bad RTC regions will need to be excluded.
Again, this is standard CMOS map, I don't know if Lenovo does it differently or how we would even confirm it.
http://www.bioscentral.com/misc/cmosmap.htm

EDIT: I'm going to try the suggested default exclusions in RTCMemoryFixup README and see if that changes anything.

[benbender]

Regarding

a) Fine :)

b)

❯ sudo ./rtcread
Password:
00: 20 59 54 56 09 10 03 01 07 20 26 02 50 81 00 00
10: 00 00 00 00 0E 80 02 00 3C 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CC
30: 00 3C 20 00 00 FF 03 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 C2 01 00 07 00 00 00 00 46 00 00 80
50: 01 00 00 00 FF FF FF FF 00 7D 00 00 00 00 00 00
60: 01 00 00 00 02 00 03 04 00 00 00 01 00 FF 01 00
70: 00 00 30 00 00 00 00 00 00 5A 00 00 49 53 B2 00
80: 44 45 41 44 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0: 87 5A 40 E1 00 00 00 00 00 00 00 00 00 00 00 00
C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0: 00 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0: 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00
Checksum is 04 81 vs 00 7D from rtc (0)

That one shows entries for 00-FF, so we would have full 256bytes and no need to fix here.

For c) So I wouldn't try to patch until necessity is clear. Btw, where did you get the IRQ-Listing from?

Regarding testing with RTCMemoryFixup I'm not sure if that's the way to go for 10.15.4+. My impression atm is that RTC is working correct for us and AppleRTC is simple overwriting the checksum fields.

I would try to approach like this, but don't have time because of work: acidanthera/bugtracker#765 (comment)

0x5859 might be actually the wrong values for us.

[benbender]

BTW, if it's not clear: Testing should be done with a debug-build of opencore and target=67/0x43 so it writes log-files for early boot in boot.efi. rtc-blacklist will most likely be handled in boot.efi.

And I would suggest to remove every other hack (ACPI, RtcMemoryFixup, boot-args, etc) around RTC-handling for testing and only try rtc-blacklist and DisableRTCChecksum.

[tylernguyen]

Source for IRQ assignments: https://www.helpwithpcs.com/upgrading/change-irq-settings.htm

0x5859 is probably the wrong values for us.

The problem is that CMOS reset doesn't happen on boot, it happens on wake of hibernation. But it doesn't really create a KP panic so what logs am I even supposed to look at to see the problem?

Also, this is likely the best description of our issue:
acidanthera/bugtracker#765 (comment)

EDIT: For reference, this is AppleRTC table: https://github.com/acidanthera/VirtualSMC/blob/master/Tools/rtcread/rtcread.c#L45
I wonder if we need to rename our RTC device and just create a fake one?

[benbender]

//
// There currently are 2 places main RTC checksum is calculated in AppleRTC.kext
// __ZN8AppleRTC14updateChecksumEv and __ZN8AppleRTC19rtcRecordTracePointEjjj.
// Since we do not want to completely break RTC and/or saving tracepoints to RTC
// we patch-out __ZN8AppleRTC8rtcWriteEjh call arguments (0x58 and 0x59) with
// invalid (out of range) value 0xFFFF in 4 places.
//

From OC-Source. So DisableRTCChecksum disables the check of 0x58 0x59 in AppleRTC and rtc-blacklist blocks writing to it.

From my rtcdump:

50: 01 00 00 00 FF FF FF FF 00 7D 00 00 00 00 00 00

And:

Checksum is 04 81 vs 00 7D from rtc (0)

00 7D would be 58/59.

I think this handles checksums on apple's software-side, but we have an additional problem in case of mode 25 hibernation where the encryption-keys for the memory-images are written to the rtc and, because of that, the rtc-checksum is b0rked at bios-level which eventually results in the bios-error at the reboot after hibernation. So we need to fix both.

From HibernationFixup-Changelog:

v1.2.1
Save hibernation keys in NVRAM only if boot-arg -hbfx-dump-nvram is specified or if the second bank of RTC memory (next block of 128 bytes) is not available

I would assume that holding the hibernation-keys in nvram should fix the issue. So my suggestion:

• rtc-blacklist 0x58/0x59
• disableRTCChecksum
• HibernationFixup Debug-build
• hbfx-dump-nvram + hbfxdbg-bootargs
• Testing & hoping - and log-checking ;)

[savvamitrofanov]

@savvamitrofanov Nice! Do you have any docs/sources for the claim about the upper memory-bank? It aligns with my experiences, but I wasn't able to find any info when I looked around...

I was able to boot relatively clean after hibernation without CSM. So it should be possible, but my tests are a bit outdated. Afaik CSM is generally discouraged in OpenCore...

Hello! Information is inside your firmware. I reversed DxeCmosInit module (95BF86AD-A1E0-4143-B487-004B1C2E05FA) which performs RTC initialization and various validation checks in upper-bank. It is clearly seen that operations are performed at port addresses 0x72, 0x73, which corresponds to 0x80-0xFF RTC Memory. Also there is routine which validates some values in upper bank, and return EFI_VOLUME_CORRUPTED if it is wrong, that causes to execute code which perform call to LenovoErrorProtocol (my guess) interface to spawn 251 error code with given text.

EFI_STATUS __fastcall ValidateChecksum()
{
  unsigned __int8 v0; // r8
  unsigned __int8 v1; // al
  char v2; // r8
  __int16 v3; // r9
  __int16 v4; // r9
  unsigned __int8 v5; // al
  __int16 v6; // r8
  unsigned __int8 v7; // al
  unsigned __int8 v8; // al
  __int16 v10; // r10
  unsigned __int8 v11; // al
  __int16 v12; // r8
  unsigned __int8 v13; // al

  v0 = 16;
  do
  {
    v1 = sub_A20(v0);
    v0 = v2 + 1;
    v4 = v1 + v3;
  }
  while ( v0 <= 0x2Du );
  __outbyte(0x70u, 0x2Eu);
  v5 = __inbyte(0x71u);
  v6 = v5 << 8;
  __outbyte(0x70u, 0x2Fu);
  v7 = __inbyte(0x71u);
  if ( v4 != v6 + v7 )
    return EFI_VOLUME_CORRUPTED;
  __outbyte(0x70u, 0x79u);
  v8 = __inbyte(0x71u);
  if ( v8 != 90 )
    return EFI_VOLUME_CORRUPTED;
  v10 = sub_A78();
  __outbyte(0x72u, 0x1Fu);
  v11 = __inbyte(0x73u);
  v12 = v11 << 8;
  __outbyte(0x72u, 0x1Eu);
  v13 = __inbyte(0x73u);
  return -(v12 + v13 != v10) & 0x800000000000000Aui64;
}

EFI_STATUS __fastcall WorkWithHigherBank(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
  EFI_STATUS Status2; // rax
  EFI_STATUS Status; // rbx
  __int64 v4; // rdx
  EFI_PCD_PROTOCOL *PcdInstance; // rax
  __int64 v6; // rdx
  UINT8 UpperOffset1E; // al
  unsigned __int8 UpperOffset1F; // al
  LENOVO_SHOW_ALERT_PROTOCOL *LenovoThrowErrorProtocolInterface; // [rsp+58h] [rbp+10h]

  LenovoThrowErrorProtocolInterface = SystemTable;
  Status2 = gEfiBootServices->LocateProtocol(&LenovoThrowErrorProtocol, 0i64, &LenovoThrowErrorProtocolInterface);
  if ( (Status2 & 0x8000000000000000ui64) == 0i64 )
  {
    Status = sub_4C8();
    if ( (Status & 0x8000000000000000ui64) != 0i64 )
    {
      WorkWithLowerBank();
      if ( Status == EFI_DEVICE_ERROR )
      {
        (LenovoThrowErrorProtocolInterface->field_8)(
          dword_C20,
          dword_C24,
          dword_C28,
          dword_C2C,
          0i64,
          off_C30,
          off_C38,
          qword_C40);
      }
      else if ( Status == EFI_INVALID_PARAMETER )
      {
        (LenovoThrowErrorProtocolInterface->field_8)(
          dword_C78,
          dword_C7C,
          dword_C80,
          dword_C84,
          0i64,
          off_C88,
          off_C90,
          qword_C98);
      }
    }
    Status2 = ValidateChecksum();
    if ( Status2 == EFI_VOLUME_CORRUPTED )
    {
      DoSomethingWithRTCMem(EFI_VOLUME_CORRUPTED, v4);
      PcdInstance = GetPcdProtocolInterface();
      LOBYTE(v6) = 1;
      (PcdInstance[1].Get16)(0x115i64, v6);
      // Work with 0x1E in upper bank
      // outportb(0x72, 0x1E)
      __outbyte(0x72u, 0x1Eu);
      // Read from 0x1E in upper bank (128-255 range)
      // inportb(0x73)
      UpperOffset1E = __inbyte(0x73u);
      if ( UpperOffset1E || (__outbyte(0x72u, 0x1Fu), (UpperOffset1F = __inbyte(0x73u)) != 0) )
      {
        // Fill 0x1E and 0x1F with 0x00
        __outbyte(0x72u, 0x1Eu);
        __outbyte(0x73u, 0);
        __outbyte(0x72u, 0x1Fu);
        __outbyte(0x73u, 0);
      }
      else
      {
        // Fill 0x1E, 0x1F with 0xFF
        __outbyte(0x72u, 0x1Eu);
        __outbyte(0x73u, 0xFFu);
        __outbyte(0x72u, 0x1Fu);
        __outbyte(0x73u, 0xFFu);
      }
      // Show 251 CMOS Checksum error
      Status2 = (LenovoThrowErrorProtocolInterface->field_8)(
                  dword_CA0,
                  ErrorCode,
                  dword_CA8,
                  dword_CAC,
                  0i64,
                  off_CB0,
                  SystemCmosEror251Msg,
                  qword_CC0);
    }
  }
  return Status2;
}

About CSM. I agree that it's not a right solution, but it gives me the vector to perform research – memory map.
I compared two memory maps with CSM and without CSM (diffcheck), and I found, that with enabled CSM – firmware allocates 1 page with EfiRuntimeCode type at the physical offset 0x8b000. Lack of such regions can cause serious problem, if this memory range used for something in runtime. So I created simple DXE driver which allocates this page, like CSM and viola. I got working hibernation.
Next step, improve ReservedMemory option in OpenCore to do such allocations out-of-box ;)
You could try OC from this branch acidanthera/OpenCorePkg@76bf9bd
Example ReservedMemory dict with hibernation fix added into Sample.plist

[savvamitrofanov]

Just for test you can load this from OpenCore drivers and check if black screen is gone
LenovoAllocateRTCodePage.efi.zip
UPD: Do not use test driver in production, use ReservedMemory option with latest OpenCore bootloader build

[benbender]

@savvamitrofanov Very interesting stuff and way above my knowledge. Will try to find time to test tomorrow. Thank you very much and keep us informed of any other findings/improvements you may make!

[1Revenger1]

The above driver helped with my X1 Extreme's black screen, though it reboots shortly after displaying the lock screen so I have some further debugging to do I think. Thanks!

Edit: Needed to enable DiscardHibernateMap and now it's working

[benbender]

Can confirm. Same result as for @1Revenger1. Thanks @savvamitrofanov! 👍

[tylernguyen]

This is great news. Thank you @savvamitrofanov !
I'm away atm but as soon as I return I'll test it myself and push it to the repo.

[vit9696]

Do not push the driver to the repository. It was meant to be a dirty test not ready for producfion. Use OpenCore 0.6.2 that has this functionality builtin via ReservedMemory section (refer to Sample.plist for exact values).

[tylernguyen]

@vit9696 That's awesome! I'll update the repo next Monday when 0.6.2 comes out then. Thank you for your work.

[benbender]

@tylernguyen Jfyi it's already implemented in https://github.com/EETagent/T480-OpenCore-Hackintosh and works fine. But from my point of view it shouldn't be the default because it's not the default on genuine Macbooks and takes substantially longer to wake. But it's a "nice to have" in case you are suffering from battery drain on sleep and for completeness.

[1Revenger1]

The default for a macbook pro afaik is Sleepmode 3 (looking at man pmset), with standby times of 12 hours above 50% battery and 3 hours below 50% battery, before going to hibernate.

[1Revenger1]

Follow up on my previous testing - so I was having an issue where if I rebooted before attempting to go into hibernate then waking up, I would see the login screen before it abruptly reset due to some error. Turns out it was possibly RebuildAppleMemoryMap causing issues. Disabling that + DiscardHibernateMap, and then enabling EnableWriteUnprotector fixed this.

[tylernguyen]

Hibernation mode 25 now supported on the repo as of 985d3a2. Enable it via the command line if that is your preferred mode. Thank you @benbender @1Revenger1 @savvamitrofanov @vit9696

[alarsama]

Hi folks! I am currently using Tyler's EFI from before 2022-8-24 and after 2022-4-20, with OC 0.8.2. The date of the entry in the changelog is not there anymore. Not sure why!

I was able to get everything working but noticed that I was encountering the 0251 CMOS bad checksum error when turning on the computer from hibernation using hibernatemode 25. My BIOS config is not reset when this happens, but it is annoying to encounter that (and the beeping) every time I wake from hibernate.

I did not understand why this was happening (especially after reading this thread) until I noticed in the changelog that "RTCMemoryFixup.kext" was removed on 2022-2-21. Out of curiosity, I added that kext back in the Kexts folder and config.plist, and set rtcfx_exclude=80-AB in my boot-args (per one of savvamitrofanov's previous comments.)

After applying the change and rebooting twice (just in case), I no longer see the error. It has only been a day and I have only tried this about 6 times, so I'll be testing this long term. Thought I would share this for anyone who might still be encountering this issue.

[tylernguyen]

@alarsama

Sorry. I was intending to update this fix with one that doesn't depend on RTCMemoryFixup.kext but entirely forgot about it.

I'll double check the issue in the coming days and get back to you.

[alarsama]

@tylernguyen no worries! Just wanted to share the solution if anyone else encountered it. I appreciate you replying and wanted to express gratitude to you for sharing your EFI for the x1c6!

[flo-at-work]

Hi,

Just wanted to share another fix for the CMOS checksum error which is to simply remove the "DxeCmosInit" (thanks @savvamitrofanov for the info) module from the UEFI Bios (with UEFITool for ex.) then flash it back (you'll need a CH341A programmer). Then no more complains about CMOS at boot.

Regards!