Intel NUC 10 Frost Canyon

[dolgarrenan]

Sorry to say the WiFi 6 is not supported by any Mac based drivers as of yet. So no the native WiFi is not working. Bluetooth is up but without a working WiFi this limits what Bluetooth usually accomplishes on a real Mac.

I have high hopes we will get working drivers from the Intel WiFi project at some point.

Hopefully one day! Can you check if you have device H_EC loading in your ioreg and if AppleACPIEC.kext is loaded in extensions?

 

[oli.mathieu]

Sorry to say the WiFi 6 is not supported by any Mac based drivers as of yet. So no the native WiFi is not working. Bluetooth is up but without a working WiFi this limits what Bluetooth usually accomplishes on a real Mac.

I have high hopes we will get working drivers from the Intel WiFi project at some point.

ok thanks
I realize that the new MacBook Pro 13 inch with Intel 10th gen CPU still use WIFI 5
Strange isn't it ?

 

[zavrus]

Has any of you managed to disable H_EC device? On its own with a simple SSDT it seems not to be working, kernel extension AppleACPIEC still loads and creating the dummy EC device does not much..

I think I also can't disable it, but at the same time I can have fake EC.

Here is what options I have.
1. I tried this SSDT-EC-USBX.dsl as a base. If there is no changes in file and no ACPI patch (Rename H_EC to EC), then I have what is on pic - two EC controllers (fake EC and H_EC native). AppleACPIEC I see connects to native one - is that wrong?


2. If I use ACPI patch (Rename H_EC to EC), then EC controller in the only in system, but it returns 0xb as in native SSDT instead of 0xf as fake one does. And I have no idea whether it's OK. Opinion? AppleACPIEC connects to this controller.


3. If I uncomment section in above mentioned SSDT-EC-USBX.dsl and rename EC0 to H_EC in new code (no matter the patch H_EC to EC is enabled or not), then I get stuck at boot. The SSDTTime utility generates SSDT-EC that has uncommented section with H_EC, that leads to stuck. By the way, I see some other errors with SSDT but don't know so far if it's ok.


I know I didn't help with your question, but for me the current (while I solve audio issues) working bootable solution is option 2.

 

[dolgarrenan]

I think I also can't disable it, but at the same time I have fake EC - is it bad? Honestly, I don't know the consequences.

Here is what options I have.
1. I tried this SSDT-EC-USBX.dsl as a base. If there is no changes in file and no ACPI patch (Rename H_EC to EC), then I have what is on pic - two EC controllers (fake EC and H_EC native). AppleACPIEC I see connects to native one - is that wrong?
View attachment 475270
2. If I use ACPI patch (Rename H_EC to EC), then EC controller in the only in system, but it returns 0xb as in native SSDT instead of 0xf as fake one does. And I have no idea whether it's OK. Opinion? AppleACPIEC connects to this controller.
View attachment 475274
3. If I uncomment section in above mentioned SSDT-EC-USBX.dsl (no matter the patch H_EC to EC is enabled or not), then I get stuck at boot. The SSDTTime utility generates SSDT-EC that has uncommented section with H_EC, that leads to stuck.

I know I didn't help with your question, but for me current working bootable solution is option 2.

Renaming H_EC to EC does not solve issue at hand, is not that H_EC will directly destroy your system but it could cause problems in the future and render your system unbootable, sucks.

As you can see your device EC now loads AppleACPIEC.kext which is the issue. None of the two SSDTs will null the device provided by the vendor (Intel) and when you configure to disable H_EC a KP occurs at boot... I'm still thinking how to solve this, surely must be something simple.

 

[CaseySJ]

I think I also can't disable it, but at the same time I can have fake EC.

Here is what options I have.
1. I tried this SSDT-EC-USBX.dsl as a base. If there is no changes in file and no ACPI patch (Rename H_EC to EC), then I have what is on pic - two EC controllers (fake EC and H_EC native). AppleACPIEC I see connects to native one - is that wrong?
View attachment 475270

2. If I use ACPI patch (Rename H_EC to EC), then EC controller in the only in system, but it returns 0xb as in native SSDT instead of 0xf as fake one does. And I have no idea whether it's OK. Opinion? AppleACPIEC connects to this controller.
View attachment 475274

3. If I uncomment section in above mentioned SSDT-EC-USBX.dsl (no matter the patch H_EC to EC is enabled or not), then I get stuck at boot. The SSDTTime utility generates SSDT-EC that has uncommented section with H_EC, that leads to stuck. By the way, I see some other errors with SSDT but don't know so far if it's ok.
View attachment 475276

I know I didn't help with your question, but for me the current (while I solve audio issues) working bootable solution is option 2.

Renaming H_EC to EC does not solve issue at hand, is not that H_EC will directly destroy your system but it could cause problems in the future and render your system unbootable, sucks.

As you can see your device EC now loads AppleACPIEC.kext which is the issue. None of the two SSDTs will null the device provided by the vendor (Intel) and when you configure to disable H_EC a KP occurs at boot... I'm still thinking how to solve this, surely must be something simple.

Please try something like this (full version attached):

 

[zavrus]

Please try something like this (full version attached):

This is actually my option 3 - as far as I see you uncommented red square code and renamed EC0 --> H_EC that goes me to the boot fail with disabled patch H_EC --> EC (no renaming). If I keep renaming patch then the screen as exactly as on my option 2.

 

[dolgarrenan]

Please try something like this (full version attached):

View attachment 475284

I tried that the very first, no joy I have the exact same issue as @zavrus , if I try to disable device H_EC, boot simply hangs. I have also tried blocking the AppleACPIEC k extension from loading within OC Block functionality and doesn't work..

This is actually my option 3 - as far as I see you uncommented red square code and renamed EC0 --> H_EC that goes me to the boot fail with disabled patch H_EC --> EC (no renaming). If I keep renaming patch then the screen as exactly as on my option 2.

I'm on the same boat, but I wouldn't honestly do renaming, all you do is move H_EC device operation to EC, if you look at your loaded extension you will see that AppleACPIEC is most likely still loading, which is what we are trying to avoid by using the ACPI configuration.

Newer Apple OS system require the use of an EC device to boot among other things, but Apple can't properly manage devices introduced by various vendors like EC0, EC or H_EC (they are incompatible) that is why we disable the ones that come with our board vendors and create a dummy EC for Apple to use which is not related to real devices on our boards.

Using vendor devices will cause problems along the line, and we don't want that.

@CaseySJ Do know of any other method to block the extension from loading besides OC built-in? If I open MaciASL and load table -> DSDT it shows the device

Return (0x0B) then Return (zero)

which should be disabled but in fact is not..

 

[svandive]

@CaseySJ Do know of any other method to block the extension from loading besides OC built-in? If I open MaciASL and load table -> DSDT it shows the device

Return (0x0B) then Return (zero)

which should be disabled but in fact is not..

I'm not sure I fully follow along, I have taken this opportunity to try and learn about the ACPI Embedded Controller however I'm not finding a lot of details that teach me the basics to understand what we are looking for here. I believe we want to enter a fake EC entry to basically block the Intel EC from being found? I can say currently in IORegistry I'm getting:

However I also know my Z390 shows all f which is what I believe it should look like.

I tried CaseySJ suggestion but that wouldn't boot properly.

@dolgarrenan or @zavrus have any pointers where I can learn about this I will absolutely make use of them.

 

[zavrus]

svandive, as far as I understood from both dolgarrenan and CaseySJ posts the only correct option is to have just one 'EC' controller with no AppleACPIEC attached to it (i.e. disabled) and returning 0xf.

If you don't have a H_EC entry below the EC entry (your picture 1 in previous post) then you are more lucky than us. So please share your ACPI aml's for EC

 

[zavrus]

And please one more question from hack-newbie - Is there anywhere the final check-list before thinking the job is done?
What I have to check (thoroughly) before I can consider configuration as final ?

At the moment I see I have next troubles with 'our' NUC10:

• no correct sound path which causes YouTube and other HTML5 content to freeze at start (either through native jack or HDMI audio though all framebuffers patches tell me everything is OK)
• sometimes I can't get my NUC awake from sleep (I hope this is EC related)
• bluetooth looks like working though handoff feature is OFF (in About This Mac) and FW loaded checkbox is not checked in Hackingtool (under System>Peripherals)
• no WiFi (it's clear it's in progress)
• SD card reader not working (I can live with it - there is a CalDigit dock)

and one more thing )) Do we need to make a USB map for NUC10 if it has less than 15 ports?