Jump to content
2,149 posts in this topic

Recommended Posts

  • 4 weeks later...
On 12/9/2020 at 11:56 PM, unixb0y said:

Today, I updated my OC installation and created a completely new EFI. I chose VirtualSMC and no W836 Kext and now I have sensor readings for my fans :D

I use now:


AppleALC.kext
IntelMausi.kext
Lilu.kext
SMCProcessor.kext
SMCSuperIO.kext
VirtualSMC.kext
WhateverGreen.kext

And I have all this good stuff. iStats also works with these Kexts!

 

Screenshot 2020-12-09 at 23.55.15.png

Screenshot 2020-12-09 at 23.55.54.png

 

Only issue with that solution: fan control is not working :/

Do you work on SMCSuperIO / VirtualSMC as well? This is all from team Acidanthera, right?

Link to comment
Share on other sites

  • 2 weeks later...
On 12/30/2020 at 8:15 AM, Paksman said:

is there anyone here successfully using opencore on Big Sur with fakesmc kext?

 

My rig running fine with OC0.6.6, FakeSMC.kext and BS11.2.

 

@Paksman This is interesting.

Edited by tonyx86
Added link to updated FakeSMC for OC
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
4 hours ago, tonyx86 said:

I posted a note about this in the OC Discussion thread and am 'double-posting' this here.  I ask for Moderator forgiveness as I think this issue is relevant to both discussions.  I am now testing this updated FakeSMC.kext with OC 0.6.6.  After I updated my rig's BIOS, I started to experience random reboots and I experienced an unexpected system restart during my upgrade from BS 11.2 to BS 11.2.1.  I suspect that these reboots/restarts were caused by incompatibility between the 'old' FakeSMC.kext and OC.  If you use XCode to edit your OC config.plist (part of the migration to the new FakeSMC), see my post here.

But you are confusing FakeSMC 6.x and 3.x. They are not different versions. They are different projects and this particular thread is about FakeSMC 3.x.

FakeSMC 3.x with plugins works fine in BigSur 11.3.1b1. No crashes etc.

Link to comment
Share on other sites

I want to announce new release 243.

IntelCPUMonitor

- added IceLake and TigerLake CPUs

RadeonMonitor

--added RX5500-5900 cards temperature monitoring

Added new plugin IntelMCHMonitor

for Kabylake and up. Testing will be in separate thread.

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, Matgen84 said:

@Slice

Thanks. :)

There are changes for FakeSMC 3.5.3 since 2019 ? or not. I only use this kext from the bundle. So I want to know, if updating is necessary. Please.

Not necessary.

I may recommend to edit his info.plist

The key MSSD will be better to be 05

Снимок экрана 2021-02-16 в 19.01.38.png

  • Thanks 1
Link to comment
Share on other sites

18 hours ago, Slice said:

Not necessary.

I may recommend to edit his info.plist

The key MSSD will be better to be 05

 

 

Hi @Slice

I've panic after change MSSD data to 05 (FakeSMC 3.5.3) on my Ivybridge config (Mojave). See screenshot. Several searches, replace by data 03 and clear NVRAM, I can boot again.

Very strange. I misunderstood something, i don't know where I mistaken

 

Spoiler

1.thumb.jpg.3c98e21880ad03c6f0e993fac341dff3.jpg


 

SOLVED: it's a problem with PDEditPlus: the tool don't save correctly data changes. I use Plist Edit Pro instead: the issue is solved. I can boot without panic.

Edited by Matgen84
  • Like 2
Link to comment
Share on other sites

4 minutes ago, Slice said:

I also have panics after info.plist editing. Strange...


I posted a comment to the developer on their thread to report the issue.

Link to comment
Share on other sites

OK now works well

hack Z370 --> BS11.3 FakeSMC.kext + IntelCPUMonitor.kext + IntelMCHMonitor.kext

2021-2-18_17-41-56_CLOVERX64-5130.efi.log

all that remains is that on restart before arriving at the desktop the writing appears: you turned off the computer due to a problem.
Of course there is no problem, which is not the case with virtualsmc

  • Sad 2
Link to comment
Share on other sites

  • 6 months later...

Hello!

 

I have a Nuvoton monitoring chip. Superiotool identified it as "Nuvoton NCT6776F/D (C) (id=0xc333)". I found out that fan registers in WinbondW836x.h are not suitable for this chip:

const UInt16 NUVOTON_TACHOMETER[] = {0x4C0,  0x4C2,  0x4C4,  0x4C6, 0x4C8, 0x4CA};

This should work (from kozlek's branch):

const UInt16 NUVOTON_TACHOMETER[] = {0x656, 0x658, 0x65A, 0x65C, 0x65E, 0x660};

I binpatched W836x.kext accordingly and now my CPU and system fans show up. This should be the datasheet. It would be nice if this could be fixed upstream. Thank you very much!

Link to comment
Share on other sites

1 hour ago, simmel said:

Hello!

 

I have a Nuvoton monitoring chip. Superiotool identified it as "Nuvoton NCT6776F/D (C) (id=0xc333)". I found out that fan registers in WinbondW836x.h are not suitable for this chip:


const UInt16 NUVOTON_TACHOMETER[] = {0x4C0,  0x4C2,  0x4C4,  0x4C6, 0x4C8, 0x4CA};

This should work (from kozlek's branch):


const UInt16 NUVOTON_TACHOMETER[] = {0x656, 0x658, 0x65A, 0x65C, 0x65E, 0x660};

I binpatched W836x.kext accordingly and now my CPU and system fans show up. This should be the datasheet. It would be nice if this could be fixed upstream. Thank you very much!

Thank you for the investigation. I can fix mainstream.

But tell me If the rule is correct for all Nuvoton chips or for a series of Nuvoton chips or just for this one or just for your case?

Link to comment
Share on other sites

24 minutes ago, Slice said:

But tell me If the rule is correct for all Nuvoton chips or for a series of Nuvoton chips or just for this one or just for your case?

 

Hello Slice,

 

sadly, I can't tell you for sure. All I know is that Linux loads the NCT677x module. Please let me know if I can help you by providing any further data! Thank you!

 

Edited by simmel
Link to comment
Share on other sites

I did some more investigation. Linux loads the module ntc6775. Sources are available here. It looks like all compatible chips (like nct6776), including mine with id 0xc333, are treated the same way.

Link to comment
Share on other sites

11 hours ago, simmel said:

I did some more investigation. Linux loads the module ntc6775. Sources are available here. It looks like all compatible chips (like nct6776), including mine with id 0xc333, are treated the same way.

Not same way. Look please the sources at your link more carefully. There are no constant 0x656 as in your example.

Link to comment
Share on other sites

3 hours ago, Slice said:

There are no constant 0x656 as in your example.

 

Sorry, I expressed myself ambiguously. I mean the code makes no difference between the NCT6776D and the NCT6776F. You are right about the constants of course.

Link to comment
Share on other sites

×
×
  • Create New...