Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8,888 posts in this topic

Recommended Posts

cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)
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

588520904_Screenshot2023-07-10at3_59_31PM.png.4b381848cbd1a18725ed8c76dd78fe1c.png

 

IOReg without DVL0 (AppleSMBusControllerICH does not load)

  Hide contents

1817508750_Screenshot2023-07-10at4_04_48PM.png.0d490a17ec873c24151130e6702b1c48.png

 

@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 by cankiulascmnfye
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

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

1846408133_Screenshot2023-07-11at11_04_43AM.thumb.png.295d5e340be38653aa0050a1c1b16f43.png

 

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

1242867956_ScreenShot2023-07-11at11_19_29AM.thumb.png.cef8a8c52ca1bfbb413e0716bd14e756.png

 

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

1100487408_Screenshot2023-07-11at11_37_09AM.thumb.png.c568b0fc13bdc6c05dd59650f9c5db77.png

 

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

823807744_Screenshot2023-07-11at12_00_42PM.thumb.png.4e6473eeb976c38780098f4d9b9d528d.png

 

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted

@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.

  • Like 1
Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted
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...

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@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 by deeveedee
  • Like 1
Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
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 by deeveedee
  • Haha 1
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted

@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.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
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 %

Screenshot 2023-07-12 at 21.43.53.png

Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted

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.

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
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 by deeveedee
Link to comment
Share on other sites
STLVNUB
STLVNUB
Posted
Posted (edited)

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 by STLVNUB
  • Like 3
Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted (edited)
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 by mnfesq
Link to comment
Share on other sites
Stefanalmare
Stefanalmare
Posted
Posted
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.

  • Like 1
Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted
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.

Link to comment
Share on other sites
rthpjm
rthpjm
Posted
Posted (edited)
On 7/19/2023 at 10:31 AM, 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?


I would advise a little further investigation first. You mention “second stage of booting”, have you tried a verbose boot?

 

The easiest method of verbose boot is to hold the Apple-CMD key and the V key at the OpenCore boot selector screen. Keep the keys pressed until the boot sequence starts. Instead of the usual Apple logo and progress bar, you should see the text console. The last few text lines are of interest when the progress “stalls”. It should give you some idea of where the issue occurs.

 

Use of the command keys is a feature in OpenCore. Your OpenCore config.plist file might need to be double-checked and/or edited to enable the keys. You only need to do this if you still get the graphical boot screens even if you have held the keys…

 

An alternative is to add the -v option to the boot-args string in the OpenCore config.plist. Edit the config.plist (using your favourite editor), find the boot-args string, add -v to the string (with a space). This will make MacOS boot into verbose mode without holding the keys. It is a semi-permanent change. To go back to the graphical boot progress, edit the config.plist file and remove the -v from the boot-args string….

 

Once you find out where the boot sequence stops, search the web for help…

 

It could be that the spinning disk is being checked by fsck, if so just be patient….

Edited by rthpjm
  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...