OpenCore General Discussion

[deeveedee]

@Stefanalmare I completely disabled my SSDT-SBUS.BUS0 ACPI patch.  Without the patch, macOS Ventura 13.4.1 still detects SBUS @1F,3

 

Spoiler

 

and AppleSMBusController still loads

 

Spoiler

 

At first glance, it appears that the BUS0 ACPI patch is completely unnecessary on my HackBookPro6,2 running Ventura 13.4.1.

[Stefanalmare]

8 minutes ago, deeveedee said:

@Stefanalmare I completely disabled my SSDT-SBUS.BUS0 ACPI patch.  Without the patch, macOS Ventura 13.4.1 still detects SBUS @1F,3

 

  Hide contents

 

and AppleSMBusController still loads

 

  Hide contents

 

At first glance, it appears that the BUS0 ACPI patch is completely unnecessary on my HackBookPro6,2 running Ventura 13.4.1.

 

H370:

Spoiler

 

 

z690:

Spoiler

 

Edited July 10, 2023 by Stefanalmare

[miliuco]

3 hours ago, Melab said:

Then what is this?

This is one of the ways (not the only one) to create the macOS installer (Apple's package program that allows you to install a version of macOS on a Mac), not the OpenCore installer (which is the package that allows macOS to be installed and running on a PC). OpenCore does not have such an installer.

 

@deeveedee  @Stefanalmare

 

I don't use any SSDT-SBUS and also have the 2 kexts loaded and the device SBUS@1F,4 in IOReg. Monterey and Sonoma.

 

Edited July 10, 2023 by miliuco

[deeveedee]

@miliuco I feel a bit hypocritical by removing my SSDT-SBUS ACPI patch, since I have so many other patches that are simply cosmetic.  Like you and Stefanalmare, my hack (SMBIOS MBP6,2) is booting and running Ventura 13.4.1 just fine without any SBUS ACPI patching.

 

@cankiulascmnfye Thank you again for directing me to your discord discussion.  @Stefanalmare Thank you for posting your examples.   Learning something new every day.

 

EDIT: I have completely removed the SBUS ACPI patches from my HackBookPro6,2.  I am no longer injecting Device Bus0 (including DVL0).  com.apple.driver.AppleSMBusController is still loaded.  I don't see any difference in the behavior of my hack.

Edited July 11, 2023 by deeveedee

[cankiulascmnfye]

9 hours ago, Stefanalmare said:

 

@deeveedee I think SBUS is very important in a hack. Can be a topic discussion. Speaking about "should not be installed", I remember that without DVL0 in that rig, com.apple.driver.AppleSMBusController does not load. So, I keep it.

 

Well, SBUS and MCHC are important so that the System Management bus works but not DVL0 which is the "Diagsvault". More info: https://github.com/acidanthera/OpenCorePkg/pull/442

 

 

[cankiulascmnfye]

19 hours ago, deeveedee said:

Ok - I will test it in my rigs.  (Just the removal of Device (DVL0) ).

 

EDIT: @Stefanalmare Below is the IOReg dump on my HackBookPro6,2 with and without SBUS.BUS0.DLV0.  My hack boots and appears to be running Ventura 13.4.1 just fine even with the missing device.

 

IOReg with DVL0

  Hide contents

 

IOReg without DVL0 (AppleSMBusControllerICH does not load)

  Hide contents

 

@Stefanalmare, @cankiulascmnfye Does it matter at all that AppleSMBusControllerICH is not loading on a hackintosh (without DLV0)?  I haven't tested much, but so far, I see no difference with and without (except for IOReg).  Maybe this is just cosmetic?

 

From the info I could gather om github, it's only important that Sbus is present in IOReg.

 

Now, if you don't inject SBUS-MCHC into the system and run  

 

kextstat | grep -E "AppleSMBusController|AppleSMBusPCI"

 

And get com.apple.driver.AppleSMBusPCI (1.0.14d1) … you're should be fine

 

If yu inject SSBU-MCHC containing the DVL0 device, you get 2 results in return – simply because of the DVL0 device is attached to the SMBUS:

 

…   com.apple.driver.AppleSMBusPCI (1.0.14d1)…
…   com.apple.driver.AppleSMBusController (1.0.18d1) …

 

From my understanding the real Diagsvault device needs to be able wo write to addresses which are disabled by default since Intel 7 Series. So there's no point in injecting DVL0 on Wintel systems. In my case. I only have to inject SSDT-MCHC to get both results.

 

In Sonoma, I get both results even without injecting SBUS and/or MCHC into my desktop (iMac20,2)

 

Edited July 11, 2023 by cankiulascmnfye

[deeveedee]

Leaving the post below for historical purposes.  I have now removed Device SBUS.BUS0 ACPI patches from my HackBookPro6,2 and my HackMini8,1 (I am no longer patching SBUS (no longer adding Device BUS0 / Device BUS0.DVL0) ).  After brief testing, both hacks continue to boot/run Big Sur, Montery, Ventura and Sonoma without any behaviorial/performance changes.  I will continue to test.  At this time, it does appear that ACPI patching of SBUS is unnecessary on hackintoshes.  The only requirement for hacks is the presence of Device SBUS, which on my hacks is already present in the unpatched ACPI.

 

=====================================================

 

@cankiulascmnfye I am no longer patching SBUS at all (not injecting BUS0).  My HackBookPro6,2 is running Ventura 13.4.1 without any issues (at least no new issues after removing the SBUS ACPI patching) and com.apple.driver.AppleSMBusController is loaded.

 

kextstat -a | grep -I smbu (Ventura 13.4.1)

Spoiler

 

Note that I am still adding MCHC via SSDT.

 

EDIT: I'm booting Big Sur, Monterey, Ventura and Sonoma with the same EFI. Unlike Ventura, kextstat in Big Sur, Monterey and Sonoma shows that com.apple.driver.comAppleSMBusPCI is loaded

 

kextstat -a | grep -I smbu (Big Sur 11.7.8, Monterey 12.6.7, Sonoma 14.0 Beta 3)

Spoiler

 

EDIT2: @cankiulascmnfye I don't know how to explain this, but after booting Big Sur, Monterey and Sonoma to test my new EFI (with the removal of SBUS ACPI patches), I rebooted Ventura 13.2.1 and Ventura 13.4.1 and com.apple.driver.comAppleSMBusPCI is now loaded in Ventura.  Note that I Reset NVRAM before booting each version of macOS.

 

kextstat -a | grep -i smbu (Ventura 13.4.1 after booting Big Sur, Monterey and Sonoma): AppleSMBusPCI is now loading

Spoiler

 

EDIT3: I now see what's happening in Ventura.  AppleSMBusPCI loads at boot, but then unloads.  After waiting a few minutes and rechecking kextstat, AppleSMBusPCI is no longer loaded in Ventura.

 

kextstat -a | grep -i smbu (Ventura 13.4.1 after waiting a few minutes after booting): AppleSMBusPCI is unloaded

Spoiler

 

Edited July 11, 2023 by deeveedee

[cankiulascmnfye]

@deeveedee I've witnessed this behavior of that driver on my system as well. At some stage I started shutting down the system before  testing changed settings, just to ensure that the state of the machine is the same each time. Maybe it loads/unloads as needed. I think the important thing is that SBUS/SMBUS is present in the IO registry.

[MacKonsti]

4 hours ago, deeveedee said:

EDIT3: I now see what's happening in Ventura.  AppleSMBusPCI loads at boot, but then unloads.  After waiting a few minutes and rechecking kextstat, AppleSMBusPCI is no longer loaded in Ventura.

Thank you again for your input and feedback @deeveedee!
The question is... what about the other macOS versions, did you notice the same behaviour?

Does this thing do anything by not loading, eventually...?

 

com.apple.driver.AppleSMBusPCI
com.apple.driver.AppleSMBusController
 

We share the same hardware between my Intel NUC8 / NUC10 and your HP Elite 800 G4/G5 (if not mistaken) so you got me thinking...

[deeveedee]

@MacKonsti Great to hear from you, mate!   After removing all SBUS ACPI patches (no longer injecting SBUS.BUS0 / SBUS.BUS0.DVL0) I don't observe any change in behavior/performance with Big Sur, Monterey, Ventura and Sonoma on my HackBookPro6,2 or my HackMini8,1.   I just made the change and am continuing to test.

Edited July 11, 2023 by deeveedee

[MacKonsti]

Thanks @deeveedee just to confirm to everyone else here too, that I also disabled completely the SSDT-SBUS.aml in OpenCore config on my NUC10i7FNH (Core i7-8700B @ 3.20 GHz) declared as MacMini8,1 and rebooted. Even let it sleep. I still get both kexts being active on Ventura; but indeed on IOReg, there's no longer a tree under device SBUS. My device is according to "lspci -nn" 00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake SMBus Host Controller [8086:02a3]

$ kextstat | grep -E "AppleSMBusController|AppleSMBusPCI"

Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
  157    0 0xffffff7f958a9000 0x1000     0x1000     com.apple.driver.AppleSMBusPCI (1.0.14d1) 3B3CBC6F-07BD-3D7E-9F2F-D738A31C290D <17 7 6 3>
  165    1 0xffffff7f9589d000 0x6ffd     0x6ffd     com.apple.driver.AppleSMBusController (1.0.18d1) 18305D5D-1310-37BC-B654-6C034FD346E7 <164 17 16 7 6 3>

I will keep using it and see if I detect anything noticeable. Thanks to everyone.

[Slice]

sudo kextstat | grep SMBus

will be enough

[deeveedee]

5 hours ago, Slice said:

sudo kextstat | grep SMBus

will be enough

kextstat | grep SMBu

is also enough

 

EDIT: This reminds me of that old game show "Name that tune."  Can anyone "name that tune" in fewer notes?

Edited July 12, 2023 by deeveedee

[cankiulascmnfye]

@deeveedee @Slice Well, if you use Grep SMbus, you get all sorts of other matches as well, like VoodooSMBUS if you use a trackpad…

 

   58    4 0xffffff8002f68000 0xffe      0xffe      com.apple.iokit.IOSMBusFamily (1.1) 02901024-7468-311C-98A7-896350D03A80 <7 6 3>
   91    1 0xffffff8004e58000 0x18000    0x18000    de.leo-labs.VoodooSMBus (3.0) C7EA611A-7A6E-3210-800F-79585B09468C <17 7 6 3>
   94    0 0xffffff8004e70000 0xf000     0xf000     com.1Revenger1.RMISMBus (1.0) 1C98C210-E89C-33DF-9DD7-36058B9AB6AC <93 91 16 7 6 3>
  146    1 0xffffff7f9589d000 0x6ffd     0x6ffd     com.apple.driver.AppleSMBusController (1.0.18d1) 18305D5D-1310-37BC-B654-6C034FD346E7 <58 17 16 7 6 3>

 

That's why I don't use it.

[Slice]

3 hours ago, cankiulascmnfye said:

@deeveedee @Slice Well, if you use Grep SMbus, you get all sorts of other matches as well, like VoodooSMBUS if you use a trackpad…

 

   58    4 0xffffff8002f68000 0xffe      0xffe      com.apple.iokit.IOSMBusFamily (1.1) 02901024-7468-311C-98A7-896350D03A80 <7 6 3>
   91    1 0xffffff8004e58000 0x18000    0x18000    de.leo-labs.VoodooSMBus (3.0) C7EA611A-7A6E-3210-800F-79585B09468C <17 7 6 3>
   94    0 0xffffff8004e70000 0xf000     0xf000     com.1Revenger1.RMISMBus (1.0) 1C98C210-E89C-33DF-9DD7-36058B9AB6AC <93 91 16 7 6 3>
  146    1 0xffffff7f9589d000 0x6ffd     0x6ffd     com.apple.driver.AppleSMBusController (1.0.18d1) 18305D5D-1310-37BC-B654-6C034FD346E7 <58 17 16 7 6 3>

 

That's why I don't use it.

So, there are some influence on SMBus from third party drivers in your case.

I have Z170

Password:
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
   64    2 0xffffff8002f68000 0xffe      0xffe      com.apple.iokit.IOSMBusFamily (1.1) 02901024-7468-311C-98A7-896350D03A80 <7 6 3>
  108    1 0xffffff7f9589d000 0x6ffd     0x6ffd     com.apple.driver.AppleSMBusController (1.0.18d1) 18305D5D-1310-37BC-B654-6C034FD346E7 <64 17 16 7 6 3>
  145    0 0xffffff7f958a9000 0x1000     0x1000     com.apple.driver.AppleSMBusPCI (1.0.14d1) 3B3CBC6F-07BD-3D7E-9F2F-D738A31C290D <17 7 6 3>
sergey@iMac CloverBootloader % 

[Max.1974]

 

Where is good to go? 😁

[mnfesq]

I have a general question that is not exclusively related to OC but here goes:

 

I am trying to completely disable SIP.  I am using the csr-active-config FF0F0000.  When I run csrutil status, I get this:

mnfesq@HPEnvy17 ~ % csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled
	BaseSystem Verification: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

This "custom configuration" appears to me to disable all of SIP's functions but I cannot get csrutil to recognize SIP as disabled.  Is there a different csr-active-config I can use that makes that happen?  Am I better off using csr-active-config 00000000 and then disabling SIP in recovery mode like Mac users do? Suggestions appreciated.

[Slice]

Why not "csrutil disable"?

 

[deeveedee]

21 hours ago, mnfesq said:

When I run csrutil status, I get this:
 

This is an unsupported configuration

This explains why you get an "unknown" status when you use csrutil to query SIP status.

Edited July 15, 2023 by deeveedee

[STLVNUB]

Well I Finally Found An EFI Folder That Works 😃

GoodBye Clover, It's Been A Wild Ride 😇

Boy Is OC Fast, Good Job Developers

Edited July 15, 2023 by STLVNUB

[mnfesq]

8 hours ago, deeveedee said:

This explains why you get an "unknown" status when you use csrutil to query SIP status.

 

I finally found the csr-active-config that disables SIP completely.  Thank you @miliuco.

 

 

Edited July 15, 2023 by mnfesq

[pananning]

Hi all, in the second stage of booting, it gets stuck at about halfway down the progress bar for 3 to 4 minutes, guessing that the SATA mechanical hard disk is causing the problem, how do I shield the SATA mechanical hard disk?

[cankiulascmnfye]

Quote

OC Releases is behind schedule pretty hard this month (Official Release It's still on 0.9.3). Usually, the next milestone should is released the first Tuesday of any given month, iirc.

 

[Stefanalmare]

6 hours ago, pananning said:

Hi all, in the second stage of booting, it gets stuck at about halfway down the progress bar for 3 to 4 minutes, guessing that the SATA mechanical hard disk is causing the problem, how do I shield the SATA mechanical hard disk?

 

If you think that the culprit is SATA HDD, unplug the power or/and SATA cable on it during the installation.

[eSaF]

7 hours ago, pananning said:

guessing that the SATA mechanical hard disk is causing the problem,

Are we still using mechanical hard drives!!!!????

As @Stefanalmare suggested, isolate by unplugging the Sata Cable to that Drive and you should be fine unless that is the drive you're trying the installation on.

If that is the case then you're in for a hard time.