Contribute
Register

Big Sur on HP EliteDesk 800 G4/G5 Mini - The Perfect MacMini8,1 Hackintosh - OpenCore

Status
Not open for further replies.
@deeveedee ,
Interesting, I did not experience any trouble upgrading XCode when 13.2.1 was first released. I too skept 13.2 due to all the problem reports.

Out of curiosity, what NVMe models are you running? I cloned my drive recently for backup and noticed a very distinguishable reduction in boot time so I started investigating differences and they seem to be related to the TRIM command support on various controllers and Monterey runs one such command when the OS loads. My drives are all SMI2262 controllers and I have noticed that the drive with the slower 2262G controller boots 15s faster than the drives equipped with the 2262ENG.
 
@rafale77 All my hacks use 512GB WD SN750s. I switched to them when I first experienced problems with the Samsung drives that came with the HP EliteDesk 800 G4 Mini and never looked back. Awesome performance - no problems. See more here.

EDIT: @rafale77 I was looking back at my experience with this HackMini8,1 and see that I had a brief experiment with ADATA here before switching to SN750.
 
Thank you! I must admit not to have tested Phison based ones yet. I never noticed any boot delays with the Silicon Motion based SSDs until upgrading to Monterey. The whitelist on Github includes drives which are both SMI and Phison based. I knew Samsung was a bad idea. What I am finding out though is that my AData based on a downgraded 2262G controller (and Samsung NAND) doesn't have the delay that my generic and AData units based on a faster 2262EN controller (and intel/Micron NAND).


Edit: And... Phison wins the day... I just pulled a stick from an old build with a generic E12 controller and indeed the boot time is even shorter than on any of the SMI based ones. It makes me wonder though if it altogether ignores the TRIM command from the MacOS... Results posted here: https://www.tonymacx86.com/threads/general-nvme-drive-problems-fatal.316546/post-2303817
 
Last edited:
I've seen some discussion about whether it is better to use WhateverGreen boot-args or DeviceProperties (e.g., boot-arg igfxonln or DeviceProperty forceOnline). After reviewing the WhateverGreen.kext code (WhateverGreen/kern_igfx.cpp), it does not appear to me that there is a "better" or "correct" way to specify these arguments and it is simply a user preference. More details below...

In the case of 'igfxonln,' WhateverGreen first looks for the boot-arg 'igfxonln' and only looks for the DeviceProperty 'force-online' if the boot-arg is not present:

Code: 
        if (PE_parse_boot_argn("igfxonln", &forceOnline, sizeof(forceOnline))) {
                enabled = forceOnline != 0;
                DBGLOG("weg", "force online overriden by boot-argument %u", forceOnline);
        } else if (WIOKit::getOSDataValue(info->videoBuiltin, "force-online", forceOnline)) {
                enabled = forceOnline != 0;
                DBGLOG("weg", "force online overriden by device property %u", forceOnline);
        }

For 'igfxagdc,' it appears that WhateverGreen looks for both the boot-arg 'igfxagdc' and the DeviceProperty 'disable-agdc' and overrides agdc with the boot-arg if it's present:
Code: 
void IGFX::AGDCDisabler::processKernel(KernelPatcher &patcher, DeviceInfo *info) {
        int agdc = info->videoBuiltin->getProperty("disable-agdc") != nullptr ? 0 : 1;
        PE_parse_boot_argn("igfxagdc", &agdc, sizeof(agdc));
        enabled = agdc == 0;
}

For 'igfxfw,' WhateverGreen first looks for the boot-arg 'igfxfw' and only loads the DeviceProperty 'igfxfw' if the boot-arg is not present:

Code: 
                        if (!PE_parse_boot_argn("igfxfw", &fwLoadMode, sizeof(fwLoadMode)))
                                WIOKit::getOSDataValue<int32_t>(info->videoBuiltin, "igfxfw", fwLoadMode);
 
deeveedee said:
I've seen some discussion about whether it is better to use WhateverGreen boot-args or DeviceProperties (e.g., boot-arg igfxonln or DeviceProperty forceOnline). After reviewing the WhateverGreen.kext code (WhateverGreen/kern_igfx.cpp), it does not appear to me that there is a "better" or "correct" way to specify these arguments and it is simply a user preference. More details below...

In the case of 'igfxonln,' WhateverGreen first looks for the boot-arg 'igfxonln' and only looks for the DeviceProperty 'force-online' if the boot-arg is not present:

Code: 
        if (PE_parse_boot_argn("igfxonln", &forceOnline, sizeof(forceOnline))) {
                enabled = forceOnline != 0;
                DBGLOG("weg", "force online overriden by boot-argument %u", forceOnline);
        } else if (WIOKit::getOSDataValue(info->videoBuiltin, "force-online", forceOnline)) {
                enabled = forceOnline != 0;
                DBGLOG("weg", "force online overriden by device property %u", forceOnline);
        }

For 'igfxagdc,' it appears that WhateverGreen looks for both the boot-arg 'igfxagdc' and the DeviceProperty 'disable-agdc' and overrides agdc with the boot-arg if it's present:
Code: 
void IGFX::AGDCDisabler::processKernel(KernelPatcher &patcher, DeviceInfo *info) {
        int agdc = info->videoBuiltin->getProperty("disable-agdc") != nullptr ? 0 : 1;
        PE_parse_boot_argn("igfxagdc", &agdc, sizeof(agdc));
        enabled = agdc == 0;
}

For 'igfxfw,' WhateverGreen first looks for the boot-arg 'igfxfw' and only loads the DeviceProperty 'igfxfw' if the boot-arg is not present:

Code: 
                        if (!PE_parse_boot_argn("igfxfw", &fwLoadMode, sizeof(fwLoadMode)))
                                WIOKit::getOSDataValue<int32_t>(info->videoBuiltin, "igfxfw", fwLoadMode);
Click to expand...
I completely agree with you. It is just a matter of personal preference. Functionally one is not better than the other. I did it the Device property way just to unclutter my boot-arg entry because I want to keep the boot-arg mostly for things I want to test quickly as it is easy to get to it and modify. It makes the config.plist slightly longer. I didn't care when I had 2 or 3 arguments but at 6-7, it was starting to get a little too long for my taste and so I decided to move as much of what of the "non variable" arguments into the device properties.

Other topic, I have been rebooting the HP mini just for kicks to observe how fast it boots... I can't believe I have been running for so long without suspecting that my SSD was causing the difference in boot time. I was convinced that it was just a different build... Took down my boot time BIOS Logo to MacOS Login from 59s down to 21s...
 
Last edited:
The upgrade to Big Sur 11.6.3 was uneventful. No problems.

Screen Shot 2022-01-26 at 9.34.03 PM.png
 
rafale77 said:
Other topic, I have been rebooting the HP mini just for kicks to observe how fast it boots... I can't believe I have been running for so long without suspecting that my SSD was causing the difference in boot time. I was convinced that it was just a different build... Took down my boot time BIOS Logo to MacOS Login from 59s down to 21s...
Click to expand...
That's great! I just measured my boot time for Big Sur 11.6.3 and found 21.65s with my iPhone stop watch. Given my slow reaction time, 21 seconds sounds about right.
 
deeveedee said:
That's great! I just measured my boot time for Big Sur 11.6.3 and found 21.65s with my iPhone stop watch. Given my slow reaction time, 21 seconds sounds about right.
Click to expand...

I've been playing around with several SSD models, cloning them over and over on various models. I only use TLC drives with DRAM cache. The incremental delay is very digital:

Cat1 -- Hynix P31/WD SN750/Phison E12&E16: 21s
Cat2 -- SMI SM2262 and SM2262G: 34s (Slow progress bar at about 25% can hear the speaker click being 13s later than the category 1)
Cat3 -- SMI SM2262ENG: 59s (Progress bar is slow from 25% and stalls at about 40% and then suddenly takes off)
Cat4 -- Samsung 9X0 EVO and Pro. Have the dreaded TRIM problem. Boots fine but performance degrades over time.

For new builds, I can definitely recommend the Hynix P31 now, though the 1TB and 500GB version may need a firmware update. It is a lot more power efficient and is faster than the SN750. I would avoid SMI based and samsung drives for MacOS.
 
@rafale77 I see that you reported your findings here. Acidanthera still claims that Hynix P31 is "Incompatible with IONVMeFamily (die under heavy load)." Hopefully they review your test results and correct this.

EDIT: See additional thread here for Hynix P31 compatibility with macOS.
 
Last edited:
Is anyone enabling Kernel > Quirk > LapicKernelPanic in their OC config.plist? Details below...

I haven't been one to follow every Dortania Guide recommendation and generally refer to the guide for Open Core configuration instruction rather than for how to hack a PC. My hacking methodology is learned primarily from Rehabman and his examples. While looking for something else, I stumbled upon the Dortania recommendation that Kernel > Quirk > LapicKernelPanic be enabled for HP machines (both Desktop and Laptop). I have not been enabling this Quirk in any of my EFIs for this HP EliteDesk 800 Mini and for my HP Envy KabyLake-R laptop.

Is anyone enabling this Quirk and if so, can you explain why you're enabling it? I have enabled this Quirk and will continue to run with it enabled to determine whether I notice any change in behavior.

Dortania Laptop Recommendation: LapicKernelPanic required for HP machines

Dortania Desktop Recommendation: LapicKernelPanic required for HP machines

EDIT: I have been running with Kernel > Quirk > LapicKernelPanic=True and also Booter > Quirk > ProtectUefiServices = False (I think I had set ProtectUefiServices to True when testing something and forgot to change it back). I'm not noticing any change in behavior with these two config.plist changes.
 
Last edited:
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top