Jump to content

2,083 posts in this topic

Recommended Posts

On 2019/6/10 at PM7点10分, vector sigma said:

对不起,下一次,昨天我的儿子几乎整天都想和  他在一起;)

谢谢!

 

Loss of key after awakening。 The computer restarted and returned to normal。2.png

3.png

1.png

1.png

Edited by jinbingmao

Share this post


Link to post
Share on other sites
Advertisement

Suppose you have this controller with an input pin where you expected to see an ambient temperature value.

To do this you have to be sure there is an thermodiod which actually measures the temperature of environment and is connected to this input pin. I am not sure if the thermodiod exists.

Share this post


Link to post
Share on other sites
40 minutes ago, Slice said:

Suppose you have this controller with an input pin where you expected to see an ambient temperature value.

To do this you have to be sure there is an thermodiod which actually measures the temperature of environment and is connected to this input pin. I am not sure if the thermodiod exists.

Existence before sleep, loss after awakening.

 

There were no problems in earlier versions.

Edited by jinbingmao

Share this post


Link to post
Share on other sites
On 6/17/2019 at 11:04 AM, Slice said:

Suppose you have this controller with an input pin where you expected to see an ambient temperature value.

To do this you have to be sure there is an thermodiod which actually measures the temperature of environment and is connected to this input pin. I am not sure if the thermodiod exists.

Can be any, I cannot not be sure is it the "Ambient" sensor, but I guess @jinbingmao already ensure this...  anyway for sure some thing is connected at ITE_TEMPERATURE_BASE_REG + index 2.

Share this post


Link to post
Share on other sites

Hi everyone, thanks to you also @Slice for your work all this time, I am considering using HWSensors3 on my new hack and wanted your kind support for adding my chipset so I can monitor fans.

 

Computer = Intel NUC8i7BEH2
Chipset Model = ITE IT8987E-VG. (per Linux device information tools)
Chipset ID = 0x8987
SMBIOS Used = Macmini8,1

 

I can imagine that recent Clover should be used and that the SMC keys used are the usual ones. But please if you need further info or dump or anything, let me know, my old hacks worked out of the box, it's the first time I am requesting assistance on such thing.

 

Anyone already using this NUC? Many thanks.

Edited by MacKonsti

Share this post


Link to post
Share on other sites
Quote

Chipset Model = ITE IT8987E-VG. (per Linux device information tools)
Chipset ID = 0x8987

I can add this ID to ITE plugin consuming it works same as other ITE chip. But for sure I need a datasheet for this chip.

Share this post


Link to post
Share on other sites
16小时前,矢量西格玛说:

可以是任何,我不能肯定它是“环境”传感器,但我想@jinbingmao  已经确保了这一点......无论如何 肯定有一些东西在ITE_TEMPERATURE_BASE_REG +索引2连接。

Platform Controller Hub( South Bridge)2.png

Edited by jinbingmao

Share this post


Link to post
Share on other sites
10 hours ago, Slice said:

I can add this ID to ITE plugin consuming it works same as other ITE chip. But for sure I need a datasheet for this chip.

 

Hi @Slice and thank you for responding. I found these:

 

ITE Official Product Description = http://www.ite.com.tw/en/product/view?mid=121

 

Quote

IT8987 is a highly integrated embedded controller with system functions suitable for mobile system applications. The IT8987 directly interfaces to the LPC bus and provides ACPI embedded controller function, keyboard controller (KBC) and matrix scan, PWM and ADC for hardware monitor, PS/2 interface for external keyboard/mouse devices, BRAM, CIR, and system wakeup functions for system power management.

 

Differences between IT8987E and IT8987E-VG are, per ITE:

 

PART NUMBER    PACKAGE TYPE                     DESCRIPTION

IT8987E               128-pin LQFP 14mm x 14mm    128KB e-Flash
IT8987VG             128-ball VFBGA 7mm x 7mm    128KB e-Flash
 

I suppose both are the same, so you could include both in the FakeSMC plugin.

 

However, the official site did not have downloads. I could only find a PDF for the datasheet only of IT8987E, despite being in the market for some time:

 

Source = http://www.datasheetcafe.com/it8987e-datasheet-pdf-controller/
Datasheet = http://datasheetcafe.databank.netdna-cdn.com/wp-content/uploads/2019/04/IT8987E.pdf

 

Are these good enough? It's a schematic rather than a datasheet :(

 

Finally, Intel's NUC mainboard description writes:

 

Quote

The hardware monitoring and fan control subsystem is based on an ITE Tech. IT8987E-VG embedded controller, which supports the following:
• Processor and system ambient temperature monitoring
• Chassis fan speed monitoring
• Voltage monitoring of CPU IO Vcc (+Vccio), Memory Vcc (V_SM), CPU IN Vcc (+Vccp)
• SMBus interface

 

Hardware monitoring subsystem: based on a ITE Tech. IT8987E-VG embedded controller, including:
• Voltage sense to detect out of range power supply voltages
• Thermal sense to detect out of range thermal values
• One processor fan header
• Fan sense input used to monitor fan activity
• Fan speed control

 

Thank you.

Edited by MacKonsti

Share this post


Link to post
Share on other sites
On 6/20/2019 at 9:10 PM, Slice said:

Thanks for electric schemes although it is not datasheet.

Anyway I created a version to test

Hope it will work somehow.

 

Sorry I could not provide a proper product sheet, can't be found anywhere. Thanks for getting the chipset into the kext, unfortunately it does not show any reading at all, despite loading OK (checked it on Terminal, result was org.mozodojo.ITEIT87x (1.0.4) etc.)

 

a) I installed in stages in /L/E/ step-by-step on my NUC (10.14.5) FakeSMC r206, then IntelCPUMonitor, then ACPIMonitor and finally the modified ITEIT87x. Does this ITE kext depend on anything i.e. any kext? Running Clover r4961

 

b) What can I do to provide you with SMC keys reported or detected? How can I help you on this? Do you want me to provide smcread output? Any special instructions?

 

c) Do I need to create a device per your old thread/guide here or do you want me to disassemble the DSDT and look for about thermal devices? I am no ACPI expert but all these years I've done some DSDT improvements...

 

d) Does IntelCPUMonitor support officially the NUC's CPU which is in this case Coffee Lake (Bean Canyon) generation? It's Intel Core i7-8559U / Intel Iris Plus Graphics 655

 

Thank you! (спасибо)

 

UPDATE: I found your SMC_util3 tool from here (says v0.01 hopefully it's the latest?) and I attach the keys detected via SMC_util3 -l >> NUC8-Keys.txt hope they help. Does it make sense to write some fake FAN value to see if it appears on your monitoring tool? Not sure what value that would be for a motherboard fan.

 

I am a little concerned because the output of SMC_Read3 has no visual indication of a FAN being reported, FNum shows 0 and I only get to recognise FRC0-FRC3 [freq] and TC0D-TC3D [sp78] could this be that Intel made the BIOS/ACPI to not report fans at all? For example, no clear indication of keys for CPU proximity or Ambient temperature etc. Not sure if these are CPU-platform dependent or machine/BIOS dependent... Can an SSDT-xxx device retrieve that FAN data?

 

NUC8-Keys.txt

Edited by MacKonsti

Share this post


Link to post
Share on other sites

@vector sigma

Intel updated IPG.

Attention, version number 3.5.5 did not change, but it is the new program.

https://software.intel.com/en-us/articles/intel-power-gadget

Good news: Now there is a IGPU Power.

I use VirtualSMC and now I see duplicating.

I think that now there is no need to receive CPU/IGPU Power from smc keys.1384291117_2019-07-061_22_39.thumb.png.80a8f8f6c81a2e5d6c79a5713efb0cf1.png

Share this post


Link to post
Share on other sites
4 minutes ago, Andrey1970 said:

Intel updated IPG.

Attention, version number 3.5.5 did not change, but it is the new program.

https://software.intel.com/en-us/articles/intel-power-gadget

Good news: Now there is a IGPU Power.

I use VirtualSMC and now I see duplicating.

I think that now there is no need to receive CPU/IGPU Power from smc keys.

Tomorrow I'll handle this by looking at the new public header. Thanks for the info!

Share this post


Link to post
Share on other sites
1 hour ago, Slice said:

HWMonitor2 works with updated IPG.

Just adjusting the translation for "GT". More I want to see if isGTAvailable() now works .. as in the old framework wasn't

..and avoid scanning for sensors when is not necessary. a smcopen() in less.

Share this post


Link to post
Share on other sites

What is needed in order to get HWMonitorSMC to work with dual CPU systems? IPG does not work with dual CPU systems, so that is out of the question.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By kevin_1351
      tl;dr: VirtualSMC causes me a flood of log messages and correlated cpu spikes. FakeSMC doesn't.
       
      Hi, I have almost finalized my Huawei Matebook X Pro Opencore setup and everything is working very well besides wifi/bt ofc (which is about to change).
       
      However, I noticed how the cpu usage sometimes went up a little and when looking at the Console I could see a never-ending flood of:
      default 14:05:05.983292+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:05.982975+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:05.982996+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985932+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985949+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.986134+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426574+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:39.426729+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426585+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431085+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431097+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431246+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433068+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:42.433227+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433078+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434453+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434465+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434622+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:44.436155+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:44.436166+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0  
      As you can see, multiple of these per second. Another guy with the same computer is also having this issue and posted a dsdt change to fix it. This fix didn't solve anything though
      He tried to limit the Notify call by implementing a state change requirement before calling Notify.
       
      Here is the original acpi:
      Scope (_SB) { Device (LID) { Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } ^^PCI0.GFX0.CLID = Local0 Return (Local0) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } Notify (LID, 0x80) // Status Change } } Which he changed to: 
      Scope (_SB) { Device (LID) { Name (_OLD, One) // assuming everything else.. the lid should start open? Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } Return (Local0) } } Device (PNLF) { Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } If ((^^^^LID._OLD != Local0)) { Notify (LID, 0x80) // Status Change ^^^^LID._OLD = Local0 } } } Besides me not seeing any reason to declare _OLD in LID. The idea itself shouldn't be too bad right? Well, as I said, his fix didn't work.
       
      In fact, to prove that Method _Q81 doesn't have anything to do with the issue at all, I created a Clover/Opencore patch to change _Q81 to XQ81. This resulted in my lid not working at all of course, but the log flooding still persisted!
      So _Q81 doesn't have anything to do with the issue afaik.
       
      Now, further Google searches led me to a chinese post where he tied the issue to VirtualSMC. And indeed, by migrating to FakeSMC the issue is no more.
       
      Unfortunately, I'm very fond of VirtualSMC for various reasons. So I would very much like to keep it. If not I'd have to implement the old way of doing Battery monitoring etcetc. Which isn't very elegant and update proof as it requires DSDT patching.
       
      So, I do believe that the issue may very well be in the DSDT code, perhaps in the ambient light part. I'm not very skilled at this and just started studying the ACPI spec 3 days ago.
       
      Could someone please help me out? Thanks a lot in advance
       
       
      origin.zip
      OC.zip
    • By Slice
      Guys,
      Don't mix 6.18 and 3.41.
       
      There are three different projects for monitoring temperatures, voltages, fans speed and other hardware parameters:
      Initially it was FakeSMC with plugins for producing SMC keys for hardware parameters for different hardware. But sometimes ago Kozlek separated own version of FakeSMC and producing new set of plugins while I stay with good working version 3. So..
      1. FakeSMC v3 with Hardware Sensors3  which I still supported.
      2. FakeSMC v6 (rev1800) by Kozlek and supported by Rehabman. AFAIK both are abandoned and the project is not supported. Or may be maintained by coauthors.
      3. New VirtualSMC by vit9696 with own set of sensors kexts. It depends on Lilu.kext. The project is in active development.
      All three project have incompatible interfaces sensors<->SMC so they are incompatible with each other.
       
      There are applications for monitoring hardware parameters and they commonly depends on these projects.
      1. iStat, iStatMenu, iStatPro compatible with real Macs because they use SMC keys just like those presents in real Macs.
      2. HWMonitorSMC by Navi (initial codes from Kozlek)  used in my HWSensors3.
      3. HWMonitor by Kozlek with graphics like in IntelPowerGadget used in his HWSensors version.
      4. HWMonitorSMC2 by Vector_Sigma tends to be universal supporting all project. It also may use sensors information produces by Apple graphics and by IntelPowerGadget.
       
      Let us discuss here differences and common ideas for this projects.
       
×