EFI pre-v.10.1 for Asus Vivobook S15

[LeeBinder]

UPDATE Mar. 1 2020:
This is work towards the upcoming v.10.1 release. It contains (among others) the following changes:

click to expand

• [SOLVED] lag in authentication dialogs (as well as a delayed login screen)/ correct SMBIOS product model
• [SOLVED] sporadic black screen on wake from sleep
• [SOLVED] keyboard backlight across all current macOS 10.13/14/15
• [IMPROVED] Touchpad: smoother more reliable overall experience
• [IMPROVED/ OPTION] Touchpad: smoother more reliable 2-finger operations
• [IMPROVED] SSDT-less USB ports approach for better Bluetooth compatibility

[whatnameisit]

Please use this USBPorts.kext instead. It correctly matches against Models MBP11,1 14,1 15,2 and 15,4.
USBPorts.kext.zip
Also, MSR 0xE2 can be considered somewhat unlocked with Pike R. Alpha's KernelAndKextPatches/KernelToPatch item MSR 0xE2 _xcpm_idle instant reboot(c) Pike R. Alpha. If it is indeed unlocked, KernelAndKextPatches/KernelPm does not have to be enabled (please see https://www.tonymacx86.com/threads/macos-native-cpu-igpu-power-management.222982/page-24#post-1584305). My Vivobook boots with the MSR patch enabled and KernelPm disabled. Then next: when checked with AppleIntelInfo.kext, CPU performance (C-states: energy saving feature in idle) is limited with KernelPm enabled (please check that Package C-State Auto Demotion and Package C-State Undemotion are enabled with KernelPm disabled or that those are disabled with KernelPm enabled). I have no idea how this all works but I think AppleIntelInfo.kext output says it's better to have KernelPm disabled.
Thanks for your hard work, @LeeBinder and @tctien342 :)

[LeeBinder]

wow great input @whatnameisit 👍 ! I already updated USBPorts.kext in both, the EFI zip and the USBPorts Issue (darn, had totally forgotten that it requires update after model change, oops).

I'll test w/o KernelPm for a while before I also update the EFI.

[LeeBinder]

Have you run some statistics if you have better battery life with KernelPm disabled?

[LeeBinder]

I'm also wondering why KernelLapic is ENabled.. From https://sourceforge.net/p/cloverefiboot/wiki/KernelAndKextPatches/#kernellapic:

HP notebooks have lapic problems, which can be solved by using the boot parameter cpus=1 or by using this option.

[LeeBinder]

.. and @whatnameisit @tctien342 : any idea why SSD Trim is DISabled? It is enabled in fewt's Vivobook Flip repo.

When I check in System Profiler/Hardware/SATA/NameOfMySSD: TRIM Support: No

After ENabling it in Clover config, reboot -> it now reads TRIM Support: YES

Pro 👍 SSD TRIM: What is SSD TRIM, why is it useful, and how to check whether it is turned on | Digital Citizen

Next I run the Trim Enabler app - it reads for my SSD "Status: DISabled". I enable it, reboot -> it now reads "Enabled" in the app.

[EDIT]: oh, Con : SSD TRIM.. : Caring for SSDs: TRIM, wear levelling and APFS – The Eclectic Light Company

So what weighs more for our Vivo hacks, pro or con?

[whatnameisit]

You bring up many good things :)
KernelLaptic, KernelPm, and many other patches really need to be tested to see if they are necessary for better performance. I will test if I have some time....
About 3rd party SATA SSD TRIM, you could choose to enable it by patching the kernel or by enabling it via terminal: sudo trimforce enable. The former way is more hack-like. The latter gives me a feeling that I have a stable system because terminal is not a hack lol. If you have an NVMe SSD you don't have to enable TRIM as it is already implemented for such SSDs.

[LeeBinder]

My TOSHIBA THNSNK256GVN8 is very most likely NOT a NVMe SSD, see Google Search results and series Pdf with specs.

I know that @tctien342 did many changes from repo to repo and performance got better and better with each release. Maybe he remembers a few things rather than running redundant tests. What I can say is that I've gone through many reboot and sleep/ wake cycles with KernelLaptic & KernelPm DIS- and SSD TRIM ENabeld, and all is fine in Mojave, Catalina (and even High Sierra) :)

[oneday95]

Can I use it on my VivoBook s510un i7?

[LeeBinder]

@dayfly that's for you to find out. Nothing to lose. Just make a new partition on your SSD, give it a try and share your results :)

[EDIT]: search results for s510un @tonymacx86.com

[oneday95]

I can boot, but I can't sleep.

[LeeBinder]

@dayfly congrats, if that is all that's not working (yet)...

Questions to you - please answer both:

1. does sleep not work, or it does but wake-up does not work?
2. does it not work only when connected to power supply, or only when on battery, or in both cases?

From my experience:

1. The VoodooI2C kext(s) are know to spoil sleep -> move both VoodooI2C kexts out of EFI/CLOVER/kexts/Other, reboot, test again (make sure you have a USB or Bluetooth mouse or USB keyboard with a touchpad connected)
2. If it's not the VoodooI2C kext(s) then you could continue with moving other kexts out of EFI/CLOVER/kexts/Other ¹, or you could follow the link I posted above and read on tonymac if others with a s510un have solved any sleep issues :)

---

¹ VoodooTSCSync, VirtualSMC and Lilu must stay; WhateverGreen and NoTouchID should stay

[oneday95]

1. Once you're in bed, you're out. You need to reboot.

2. The same cannot be locked when the battery is charged and the battery is not charged.

I am sorry for my lack of English skills.

[LeeBinder]

@dayfly please look at my posting in Korean. Also I recommend you use Google Translate Korean -> English ;).

[LeeBinder]

The release is 99% ready, just missing the final touches in the ReadME.md with instructions for best possible compatibility with most models. I'm off for a quick vacation now and hope to be able to update when I'm back Thursday or Friday.

[oneday95]

No sleep effect When you wake up and wake up, the screen stays black.

Even if the battery is connected and the battery is not connected, the screen remains black when you wake up.

[whatnameisit]

@LeeBinder
AsusSMC: The release version provided by hieplpvip's git is not loaded in 10.15.2. Latest AsusSMC git and Lilu and VirtualSMC debug kexts correctly build AsusSMC.kext for working fn+f1 to f9 (and fn+10 to 12 if you count the sound keys that already work without this kext). I checked to see if it's the update on Lilu and VirtualSMC that broke compatibility with the 1.2.0 release, but I'm afraid not. For me, only the custom built AsusSMC.kext works.
Fn+1 and 2 for Sleep and Airplane mode work if AsusSMCDaemon is installed. Please consider adding information on how to install this file: https://github.com/hieplpvip/AsusSMC/wiki/Installation-Instruction
DW1560 does not need BT4LEContinuityFixup.kext or FakePCIID.kext and FakePCIID_Broadcom_Wifi.kext. AirportBrcmFixup.kext and BrcmPatchRAM are enough for working Wi-Fi, Bluetooth, and continuity features.
As for KernelPm, running AppleIntelInfo.kext shows C-states are enabled with KernelPm disabled which is supposed to be good for saving power when the CPU is in idle as I have said before. But I don't really fell the difference when it comes to battery life.
KernelLaptic is said to be only for HP laptops as you have found. Enabling/disabling it has no effect on our laptops.
I don't want to put a burden on you, but improvements are good? haha...
Thank you for all your hard work on preparing an all-in-one solution for Vivobooks!
@dayfly님 제 깃허브 Issues에 한국어로 글 남기세요.

[LeeBinder]

thanks @whatnameisit for your input! I included your hints into the new RC (but not uploaded yet, hoping for tomorrow).

Hieplvip's new AsusSMC 1.2.1 works fine in 10.13.6 - 10.15.3 here together with most recent Lilu 👍 !

I made a one double-click installer for the daemon.

I don't have the DW1560 but the FRU 04X6020 (which is a BCM94352Z NGFF M.2, too, just from Lenovo). Ever since acidanthera took over the Brcm[..] package., It does not require BrcmPatchRAMx (2 resp. 3 for Catalina) + BrcmFirmwareRepo anymore, but only BrcmBluetoothInjector (BrcmPatchRAMx & BrcmFirmwareRepo must be removed then). Works fine even after several sleep cycles, tested in Mojave and Catalina.

From what I read the DW1560 should be fine with just the BrcmBluetoothInjector, too. Have you tested that yet?

[LeeBinder]

@dayfly: -> Google 번역 을 통해 한국어로이 게시물보기 <-

When you write "No sleep effect": when you see the LED blink on the left side, it means that your Vivobook DOES sleep. When you then see a black screen on wake-up, it means you have a wake-up problem, not a sleep problem.

When you try to put your Vivobook to sleep and the screen goes black, but you do NOT see the LED on the left side blink after a while, it means your Vivobook does NOT even sleep correctly.

Also again, you would need to deactivate kexts one-by-one, reboot, etc.

But maybe whatnameisit has been helping you already.

[whatnameisit]

@LeeBinder
I remember DW1560 working fine with BRCMBluetoothInjector.kext only then switch to having all three kexts(Repo, RAM3, and Injector), but now as I read the documentation only the Injector can be used if it works. Thanks for reminding me! But I have tested my bluetooth with only the Injector kext and it worked once with warm boot from RAM3 installed Catalina, but sleep broke it. I guess different DW1560 variants have different bluetooth devices, some with firmwares better compatible on macOS and some not.
I checked the new AsusSMC and it correctly loads.
Before editing this comment, I also asked if anything changed regarding the touchpad on 10.15.3 because mine kept repeating clicks when I performed a single one-finger click down. I did not turn on the laptop for a day, and today the problem was gone. I have no idea why...
Anyways, thanks for the information regarding AsusSMC and BrcmPatchRAM!

[LeeBinder]

OK. So maybe I should make two entries in the Wi-Fi/ BT folder, one for the DW1560 and one for the FRU 04X6020, because the FRU 04X6020 has issues with acidanthera's BrcmPatchRAMs/ BrcmFirmwareRepo.

Keep in mind that in Catalina, BrcmPatchRAM3.kext also requires BrcmBluetoothInjector.kext to be installed: starting with macOS 10.15, this is the ONLY supported configuration because due to framework changes, BrcmPatchRAM.kext and BrcmPatchRAM2.kext are incompatible with macOS 10.15. In case you forget to install BrcmBluetoothInjector.kext, Bluetooth will appear to be available but won't work at all.

BrcmPatchRAM3 HAS TO be installed to /Library/Extensions. BrcmBluetoothInjector also works from EFI/Clover/kexts/Other (but does work from L/E, too),

and

In Mojave or High Sierra, if you use BrcmFirmwareRepo and BrcmPatchRAM2 (from /Library/Extensions, because they do NOT work from EFI/CLover/kexts/Other!), you HAVE TO remove BrcmBluetoothInjector.kext (make sure it is not present in either L/E or in E/C/k/O)!

eek

[LeeBinder]

Just a bit of write-up left for the VoodooI2C section (tomorrow, getting too late now), then I can upload the final RC2 for the final review :)

@whatnameisit can you try only BrcmBluetoothInjector.kext + /L/E/BrcmPatchRAM3 (BrcmFirmwareRepo removed) in Catalina with your DW1560 with BT on, do a couple of sleep/wake cycles and see if all is fine?

[whatnameisit]

@LeeBinder I don't know who said BrcmPatchRAM3 has to be installed to /L/E, but nowhere in Acidanthera's BrcmPatchRAM readme says so. It's always worked from /C/K/O for me(Injector, Data, RAM3).
BrcmBluetoothInjector and BrcmPatchRAM3 does not update the firmware. That's the job of BrcmFirmwareRepo or BrcmFirmwareData. Maybe the firmware injected from having installed Injector, RAM3, and (Repo or Data) to later install Injector and RAM3 may survive warm boots and sleep/wakes, but a cold boot will definitely break it.

[LeeBinder]

@whatnameisit good, fine work. Here's what I've been able to find out (surprise surprise ;)), at least for my Lenovo FRU 04X6020..

As per RehabMan (and taken over by Acidanthera at acidanthera/ BrcmPatchRAM):

BrcmFirmwareRepo.kext: Install to /System/Library/Extensions (/Library/Extensions on 10.11 and later). This kext is slightly more memory efficient than BrcmFirmwareData.kext, but cannot be injected by a bootloader.

RehabMan kept on insisting to please use the repo kext installed to L/E (vs. the data kext in C/k/O), so that's what I've always stuck with, with 100% success.

What is not mentioned in the ReadMe but spread somewhere in the forums is that (at least for the FRU 04X6020), once one uses BrcmFirmwareRepo.kext from L/E, ANY OTHER necessary kext(s) from the BrcmPatchRAM package (10.11-10.14: BrcmPatchRAM2; 10.15: BrcmPatchRAM3 + BrcmBluetoothInjector) ALSO have to be installed to L/E, AND removed from C/k/O (except when inject kexts = no) - otherwise no BT!

It'd be good to know if the same applies to the DW1560. A simple and telling test would be,
In Catalina (step-by-step):

• open BT pref pane and remove one or all BT entries
• turn BT off
• remove BrcmBluetoothInjector and BrcmFirmwareData from C/k/O (but leave BrcmPatchRAM3!)
• install only BrcmBluetoothInjector and BrcmFirmwareRepo to L/E
• repair perms for L/E & rebuild kext cache
• Shut down (NOT reboot)
• Power back up and boot into Catalina

• turn BT back on
• see if the removed device shows up again. If yes, try to re-add it and perform a task (send file, connect to network, etc.)

If that fails (as it does for my FRU 04X6020):

• turn BT off
• install BrcmPatchRAM3 to L/E and remove it from C/k/O
• repair perms for L/E & rebuild kext cache
• Shut down (NOT reboot)
• Power back up and boot into Catalina

• turn BT back on
• see if the removed device shows up again. If yes, try to re-add it and perform a task (send file, connect to network, etc.)

If you're also curious about this, it would be awesome if you could share your findings with your DW1560 - I would the instructions in the ReadMe :) 👍

[whatnameisit]

@LeeBinder I have used both Repo and Data according to what's written in RehabMan's and Acidanthera's BrcmPatchRAM Readmes.
/L/E: BrcmFirmwareRepo, BrcmPatchRAM3, and BrcmBluetoothInjector for Catalina (and BrcmFirmwareRepo and BrcmPatchRAM2 for Mojave and older) if you need to upload the firmware by BrcmFirmwareRepo.
/C/K/O: BrcmFirmwareData, BrcmPatchRAM3, and BrcmBluetoothInjector for Catalina (and BrcmFirmwareData and BrcmPatchRAM2 for Mojave and older) if you need to upload the firmware by BrcmFirmwareData.
There are other configurations if you make a custom injector such as /C/K/O: BrcmFirmwareRepo and BrcmCustomInjector.
At the end of the step-by-step you wrote, you have all three kexts(Repo set) in /L/E. I can test what you have told me, but I have a feeling I will end up with the three kexts in /L/E.

[LeeBinder]

Right on. I would just say "opt to upload" rather than "need to upload", but other than that, you nailed it as usual.

For the release (aim: tonight) I will not include the kexts pre-established in C/k/O, but present L/E as location for manual installation - for two reasons:

1. realistic relevance: not everyone is / will be using a swapped card to begin with - some will simply be using a USB dongle.

2. reliability: having the data kext in C/k/O + the repo one in L/E & and the other kext(s) in both locations might deliver mixed results esp. with injectKexts set to "detect". I have not made good experiences with such constellations in the past.

(I know some in the h'tosh-verse suffer from L/E phobia, but that's a fantasized disorder I don't deal with .. ;) )

[LeeBinder]

@whatnameisit EFI v.10.0 RC2 for Asus Vivobook S15.zip (21,2 MB) 👍 :)

[whatnameisit]

Nice!!
I hope everything works as expected when I get home to test it.
Great Work!

[LeeBinder]

Thanks. I already did several updates live in the repo incl. AR-CADE's "no keyboard backlight after sleep in Catalina" fix.

For you to note: what fixed the erratic/ spastic pointer movements for me here with the ELAN 1300 were three separate things!! For me this only works in GPIO not in polling mode, even with your SSDT. I mirrored all of them in the repo so people with ELAN 1200 Vivobooks should preferably use your repo (first and try this repo only in case of issues). I thought it makes most sense to offer selective and distinct options. I'll actually link to your repo, too, from the ReadMe (later or tomorrow).

You can read the details by following the first two links at [STICKY] TOUCHPAD » consolidated links to related issues.

[whatnameisit]

I haven't actually tested the EFI yet, but here's what I can say.
GPI0._STA to XSTA is applied to ignore the code that disables the GPIO device so it can be used in GPIO pinning and, therefore, activate the trackpad in the interrupts mode together with some patches applied to I2C1.ETPD._CRS. If _CRS is not patched to return both SBFB and SBFG (original DSDT returns only SBFI in _CRS), no interrupts mode and GPIO._STA to XSTA is useless.
#25 (comment) : When I said no patches were needed to activate Vivobook touchpads in polling mode, I meant renames (GPI0._STA to XSTA and _CRS to XCRS) and add-ons (SSDT-ELAN.aml) were not needed and, therefore, should be disabled.
To elaborate a little more, if _STA is changed to XSTA, then there is now live GPI0 device to enable allow GPIO pinning. But if _CRS is changed to XCRS, then there is no _CRS in ETPD which VoodooI2CHID needs for either polling or interrupts mode (even though GPI0 is enabled), resulting in unknown behaviors (I haven't tested it, but you said erratic/spastic pointer movements, so this is it I guess). That's why the V9 EFI has SSDT-ELAN.aml which adds new GPI0._STA and ETPD._CRS.
So if you have been using the recent SSDT-I2C1_USTP.aml with _CRS to XCRS then the touchpad may fail at any moment. (It's OK to keep GPI0._STA to XSTA because this SSDT and polling configuration does not interact with GPI0 at all.)
On the other hand, if you use SSDT-ELAN.aml with _CRS to XCRS disabled, then you have two _CRS in your ACPI which may fail at any moment. Since the OEM DSDT is first loaded and add-on SSDTs and ACPI patches are applied by Clover, I can assume that your touchpad is actually using the _CRS in DSDT and ignoring that in SSDT-ELAN.aml and, therefore, polling mode.
I will test V10 EFI on Thursday when I get my day off from work :)

[LeeBinder]

wow - I really appreciate the in-depth explanation. As understandably as you write it I can even make sense of it 🥇

No matter what, there must be an error in the _CRS to XCRS patch. From what I remember, hieplvip shared it with tctien342. Last time I checked hieplvip's repo ReadMe, he was also mentioning something like "random erratic pointer movements".

This is the only entry in ioreg when I search for GPIO:

I do not know how to positively determine in ioreg if polling or GPIO mode is active for the touchpad. Do you know if the spot in the image is the correct one, or do I need to look elsewhere?

Next I'll simply move SSDT-ELAN (= GPIO) out of ACPI/patched, reboot, look at ioreg again, and above all see if pointer movements remain 100% stable. Just can't do that right now but need to do it later.

[whatnameisit]

_CRS to XCRS itself does not complete the patch needed for VoodooI2C. If a new _CRS is added via an add-on SSDT(SSDT-ELAN.aml), it returns both SBFB and SBFG, and GPI0 is enabled(GPI0._STA to XSTA), then the trackpad is activated in interrupts mode. But Asus laptops have buggy GPI0 implementation, so interrupts mode may not work smoothly, and that probably is where he meant "random erratic pointer movements."
Here's how you can check the VoodooI2C mode: boot into macOS., and within 10 minutes type in the below line into the terminal.
log show --predicate 'process == "kernel"' --last 10m
It will then show something like "No APIC or GPI0 pinning found. Falling to polling if satellite has feature" That's how I know I'm using polling mode.

[LeeBinder]

mindblowing! I just have a minute now (will post log results of different configs in spoilers later): you are right, mode is reverted back down to polling with _CRS to XCRS patch DISabled even with GPIO SSDT ENabled, which is obviously not sufficient all by itself.

I am now back on your SSDT-I2C1_USTP.aml + relevant (even though not mandatory as you wrote before) settings in clover.plist/ACPI - now observing performance. Bummer I have never been able to reliably reproduce the erratic movements on demand - they were always just happening at some point.

More later.

[LeeBinder]

All below with VoodooI2C v.2.0.3 which I will stick with for now. I did not always copy/ paste all VoodooI2C related entries.

I am now running and testing your SSDT-I2C1_USTP.aml + "ELAN: change USTP to XSTP" + "ELAN: disable I2C0" because from what I recall that's the only combo I had never run on so far with VoodooI2C v.2.0.3. So far so good :)

click to expand

SSDT-ELAN.aml + "ELAN: change Method(_STA,0,NS) in GPI0 to XSTA" (DISabled: "change Method(_CRS,0,S) in ETPD to XCRS"):

GPIO entry in ioreg

2020-02-04 23:55:01.107453+0100 0x505      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::VoodooI2CDeviceNub Warning: Incompatible APIC interrupt pin (0x6d > 0x2f) and no GPIO interrupts found; if your chosen satellite implements polling then VoodooI2CDeviceNub will run in polling mode.

and

2020-02-05 00:55:31.261892+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-02-05 00:55:31.261893+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-02-05 00:55:31.262231+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [^^GPI0._STA]
2020-02-05 00:55:31.262231+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [^^GPI0._STA]
2020-02-05 00:55:31.262596+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2020-02-05 00:55:31.262596+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2020-02-05 00:55:31.263684+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/psargs-463)
2020-02-05 00:55:31.263684+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/psargs-463)
2020-02-05 00:55:31.270603+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [_CRS] @000FD #002D:
2020-02-05 00:55:31.270604+0100 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [_CRS] @000FD #002D:

SSDT-ELAN.aml + "change Method(_CRS,0,S) in ETPD to XCRS" + "ELAN: change Method(_STA,0,NS) in GPI0 to XSTA":

GPIO entry in ioreg

2020-02-05 00:07:01.924945+0100 0x576      Default     0x0                  0      0    kernel: I2C0: family specific matching fails
2020-02-05 00:07:01.925873+0100 0x577      Default     0x0                  0      0    kernel: I2C1: family specific matching fails
2020-02-05 00:07:01.926098+0100 0x576      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d60 Starting I2C controller
2020-02-05 00:07:01.926337+0100 0x577      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d61 Starting I2C controller
2020-02-05 00:07:01.926392+0100 0x576      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d60 Set PCI power state D0
2020-02-05 00:07:01.926665+0100 0x576      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d60 Publishing nub
2020-02-05 00:07:01.927605+0100 0x578      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Probing controller
2020-02-05 00:07:01.927691+0100 0x577      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d61 Set PCI power state D0
2020-02-05 00:07:01.927959+0100 0x577      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d61 Publishing nub
2020-02-05 00:07:01.938185+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Probing controller
2020-02-05 00:07:01.938588+0100 0x578      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Found valid Synopsys component, continuing with initialisation
2020-02-05 00:07:01.938927+0100 0x578      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerNub::pci8086,9d60 SSCN not implemented in ACPI tables
2020-02-05 00:07:01.939373+0100 0x578      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerNub::pci8086,9d60 FMCN not implemented in ACPI tables
2020-02-05 00:07:01.939897+0100 0x578      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Warning: Error getting bus config, using defaults where necessary
2020-02-05 00:07:01.949643+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Found valid Synopsys component, continuing with initialisation
2020-02-05 00:07:01.949664+0100 0x578      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Publishing device nubs
2020-02-05 00:07:01.949966+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerNub::pci8086,9d61 SSCN not implemented in ACPI tables
2020-02-05 00:07:01.950088+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerNub::pci8086,9d61 FMCN not implemented in ACPI tables
2020-02-05 00:07:01.950312+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Warning: Error getting bus config, using defaults where necessary
2020-02-05 00:07:02.126360+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Publishing device nubs
2020-02-05 00:07:02.135837+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Found I2C device: ELAN1300
2020-02-05 00:07:02.145683+0100 0x57a      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CDeviceNub::Got GPIO Controller! VoodooGPIOSunrisePointLP

Without any ELAN SSDT: "change Method(_CRS,0,S) in ETPD to XCRS" (DISabled: "ELAN: change Method(_STA,0,NS) in GPI0 to XSTA"):

-> as expected no touchpad functionality at all + in sys prefs "No TP found"

Without any ELAN SSDT + both DISabled, "change Method(_CRS,0,S) in ETPD to XCRS" / "ELAN: change Method(_STA,0,NS) in GPI0 to XSTA":

as expected no GPIO entry in ioreg

2020-02-05 01:32:45.799695+0100 0x469      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Warning: Error getting bus config, using defaults where necessary
2020-02-05 01:32:45.799698+0100 0x46b      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Found I2C device: ELAN1300
2020-02-05 01:32:45.799965+0100 0x469      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Publishing device nubs
2020-02-05 01:32:45.800006+0100 0x46b      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::VoodooI2CDeviceNub Warning: Incompatible APIC interrupt pin (0x6d > 0x2f) and no GPIO interrupts found; if your chosen satellite implements polling then VoodooI2CDeviceNub will run in polling mode.

SSDT-I2C1_USTP.aml + "ELAN: change USTP to XSTP to assign default values to SSCN and FMCN" + "ELAN: disable I2C0" (DISabled: "change Method(_CRS,0,S) in ETPD to XCRS" / "ELAN: change Method(_STA,0,NS) in GPI0 to XSTA"):

2020-02-05 00:49:00.289422+0100 0x460      Default     0x0                  0      0    kernel: I2C1: match category IODefaultMatchCategory exists
2020-02-05 00:49:00.289508+0100 0x460      Default     0x0                  0      0    kernel: I2C1: match category IODefaultMatchCategory exists
2020-02-05 00:49:00.297993+0100 0x45f      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d60 Set PCI power state D0
2020-02-05 00:49:00.298303+0100 0x45f      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CPCIController::pci8086,9d60 Publishing nub
2020-02-05 00:49:00.299662+0100 0x48c      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Probing controller
2020-02-05 00:49:00.299729+0100 0x490      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Probing controller
2020-02-05 00:49:00.299853+0100 0x490      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Found valid Synopsys component, continuing with initialisation
2020-02-05 00:49:00.300253+0100 0x490      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerNub::pci8086,9d60 SSCN not implemented in ACPI tables
2020-02-05 00:49:00.300308+0100 0x45f      Default     0x0                  0      0    kernel: I2C0: match category IODefaultMatchCategory exists
2020-02-05 00:49:00.300418+0100 0x45f      Default     0x0                  0      0    kernel: I2C0: match category IODefaultMatchCategory exists
2020-02-05 00:49:00.300740+0100 0x490      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerNub::pci8086,9d60 FMCN not implemented in ACPI tables
2020-02-05 00:49:00.301038+0100 0x490      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Warning: Error getting bus config, using defaults where necessary
2020-02-05 00:49:00.301576+0100 0x490      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d60 Publishing device nubs
2020-02-05 00:49:00.313918+0100 0x48c      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Found valid Synopsys component, continuing with initialisation
2020-02-05 00:49:00.314296+0100 0x48c      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Got bus configuration values
2020-02-05 00:49:00.314611+0100 0x48c      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Publishing device nubs
2020-02-05 00:49:00.327773+0100 0x48c      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::pci8086,9d61 Found I2C device: ELAN1300
2020-02-05 00:49:00.328686+0100 0x48c      Default     0x0                  0      0    kernel: (VoodooI2C) VoodooI2CControllerDriver::VoodooI2CDeviceNub Warning: Incompatible APIC interrupt pin (0x6d > 0x2f) and no GPIO interrupts found; if your chosen satellite implements polling then VoodooI2CDeviceNub will run in polling mode.

@whatnameisit, how did you see that w/o SSDT-I2C1_USTP.aml your battery was getting drained? Somewhere in Activity Monitor?

[whatnameisit]

ENAL: change \USTP to \XSTP is not needed as \USTP can be ignored and _SB.PCI0.I2C1.USTP is added via SSDT-I2C1_USTP.aml.
ELAN: disable I2C0 was the fix for the touchpad to randomly stop functioning in all previous versions of VoodooI2C and also was the culprit behind the most recent VoodooI2C. I think, if you plan on making VoodooI2C fail to attach to I2C0, it'd be better to delete the match ID for I2C0 in VoodooI2C.kext/Contents/Info.plist which is the pci8086,9d60 entry because modifying the kext's Info.plist does not cause reboot issues which I checked a month ago.
And I don't think I said about battery myself. If I did, it's either that I was wrong or my English lol. Can you quote me, please?

[LeeBinder]

allright, great info, will do tomorrow.

What I had in mind from you re. "high CPU usage" was this from Dec 18, 2019:

The SSDT is definitely needed (at the moment) for my trackpad to work smoothly. If I don't have it, any touch input may fail with high CPU usage.

[whatnameisit]

Oh, I watched the CPU frequency go up in Intel Power Gadget and touchpad inputs only worked for a couple seconds. that's what I meant... Sorry for confusion.

[LeeBinder]

;)
I just updated my local config then the live repo here with the changes you proposed. So please download the repo if you feel like testing.

From this part of the globe: good night.

[whatnameisit]

Good night!
I wonder how you understood when I said "ELAN: disable I2C0.... also was the culprit behind the most recent VoodooI2C." I meant failed to wake from sleep and instead reboot with the most recent VoodooI2C. I will test later today in Korea :)

[LeeBinder]

LOL, suspicion acknowledged, I didn't understand what you meant, but so what..

So the I2C0 pci8086,9d60 cleared VoodooI2C might even help @dayfly with his "sleep not working" issue (unless this is resolved already)

[LeeBinder]

hey @whatnameisit , how's the testing been over there in Korea? I hope your Vivo didn't blow up, silencing you ever since .. ;)

FYI, I just released the final v.10

https://github.com/tctien342/Asus-Vivobook-S510UA-Hackintosh/releases

https://github.com/tctien342/Asus-Vivobook-S510UA-Hackintosh

[whatnameisit]

@LeeBinder
Hey, I was being lazy and didn't test things until today, sorry for the delay.
There's one minor thing with USBPorts.kext where the model match for MBA8,2 is still MBP11,1.
USBPorts.kext.zip
That aside, the release boots to installer and installed volume just fine.
There is one thing with KernelPm which is not needed as MSR was patched thanks to Pike R. Alpha. As I have said, C7 state is enabled if KernelPm is disabled, which theoretically saves power in idle. And it also helps enable HWP.
log.txt
Other than that, everything should work perfectly. The kexts will have to be updated, especially WhateverGreen to 1.3.7 if you want to run 10.15.4b2+.
To comply with Acidanthera's recommendation many things have to be fixed or removed like unnecessary ACPI patches and fixes. You can reduce down to about 14 items, but then the SSDTs also need to be modified. And this has no effect for now, unless Clover becomes deprecated and OpenCore replaces it. If you have it in mind, I can make an EFI folder for OpenCore as I have switched to it.
Great work!

[LeeBinder]

thank you @whatnameisit for looking so thoroughly!

USBPorts.kext: darn, it's also necessary to change the name inside a -XHC entry

KernelPm: darn #2 - I had corrected that in my local config.plist and in the 15,2 one of the release. Maybe too late into the nite back then..

I applied both changes (+ Kernel LAPIC was still active in one of the configs - sigh). That's why we learn that quality control is indispensable LOL.

Beta kexts: yes, I see them in Hackintool, but I decided to stick with stable release versions because everyone who decides to test macOS dev versions can update kexts themselves.

OpenCore: I have been somewhat aware of that boot loader only out of the corners of my eyes and also saw that you offer it in your repo. What is its advantage in comparison with Clover - anything real-life tangible/ measurable like macOS speed, less memory footprint, cooler CPU, better battery life, stability ect.?

[whatnameisit]

@LeeBinder
Personally I can't really tell the difference between Clover and OpenCore. There are more downsides with OpenCore for now because a config.plist needs to be written for it and so many things have to be modified on top of that. It will only be useful if Clover becomes deprecated. When that happens someone will need to make an OpenCore EFI folder for our Vivobooks and I can probably provide one. But again, no need to rush anything right now.

[LeeBinder]

Gotcha, thanks for the offer.

BTW, CodecCommander 2.7.2 does not work for me - my working combo has been CC 2.7.1 + AppleALC 1.4.6. No sound deactivating even across boots betw. 10.13/14/15.

(CC is still necessary here for mike input even with AppleALC 1.4.6 from what I remember testing (haven't tested AppleALC 1.4.7 stand-alone yet)).

[whatnameisit]

I haven't tested AppleALC 1.4.5+. I will test 1.4.6 when I get home from work. AppleALC has not replaced CodecCommander for all hackintoshes because there are issues with AppleALC not being able to incorporate the verbs that CodecCommander used to send. It may become deprecated for Vivobooks with CX8050 if sound detection never fails and HDMI sound works with layout-id 3(input, output, HDMI used with CodecCommander) and 13(input, output, no HDMI used w/o CodecCommander) combined into a new layout-id. I don't know how to do that, but it should work. I hope someone comes in along and makes a new layout-id lol.

[whatnameisit]

Hey @LeeBinder
Here are a few things:
1.

Users with VivoBooks with the ELAN 1200 Touchpad are advised to rather use whatnameisit's X510UA-BQ490 repo!

I thank you for directing people to look at my repo. It's true ELAN1200 works great on my X510UA, but my build isn't focused on ELAN1200, rather on cutting out unnecessary patches for X510 laptops without keyboard backlight and NVidia Graphics (and OpenCore). And your release 10.0 works great on my laptop, so there is really no need to reference my repo. I'm just worried people will start asking why the keyboard backlight wouldn't work or have sleep and screen issues (graphics related).

Fenvi manufactured a M.2 NGFF A+E card based on the chipset BCM94360 which is native on macOS. It's name is BCM94360NG and its performance is very similar to DW1560 and the variants. The former is a lot cheaper than DW1560 and is native so should work without AirportBrcmFixup.kext or the BrcmPatchRAM package. This product is very new and there are not many reviews. Maybe you can wait and see how it turns out. One build and one discussion that I found: https://github.com/BrushXue/Z170i-Pro-Gaming-Hackintosh , osy/HaC-Mini#197

AppleALC 1.4.6 has not caused any sound deactivation so far.

Thanks :)

[LeeBinder]

hey @whatnameisit - good to hear you're alive & kicking in South Korea!

1. ah yes, I had that on my radar before - corrected!

2. very neat find, thanks for sharing! LOL, so Fenvi even plagiarized Apple's ven/ dev IDs. No wonder Donald detests China .. ;) I updated ReadMe and Wi-Fi & Bluetooth ReadMe

3. fun to hear, same here.

My plan is to make a new 10.1 release incl. updated kexts shortly after the release of 10.15.4 final.

[LeeBinder]

#49 (comment) - (Un)Mount HDD.app :)

[LeeBinder]

https://github.com/alexandred/VoodooI2C/releases/tag/2.4

• Do not use BUILD_HOME in the CI flows
• CI updates (#272)
• Update VoodooInput git submodule
• Update VoodooGPIO git submodule
• Remove deprecated VoodooI2CUPDDEngine git submodule (#271)
• Update VoodooI2CHID and VooodooGPIO git submodules (#270)
• Use Xcode 11.3 recommended settings
• Update VoodooI2CHID (#268)
• Update VoodooI2CHID git submodule (#261)

@whatnameisit in case you have not seen yet 👍

[abhishekthomasv]

hi sir would u mind sharng your efi folder.I had been running catalina on my asus vivobook s15 s510u .But when wake from sleep t used to go to a black screen and stuck there.It would be great if you could share me the efi folder sir.

[LeeBinder]

@AbhishekRMX1901 try this here and report back, please.

[abhishekthomasv]

@AbhishekRMX1901 try this here and report back, please.

okayy sir thank you i will

[LeeBinder]

This repo has found a new home at the current maintainer's GitHub corner:

https://github.com/LeeBinder/Asus-Vivobook-S510UA-Hackintosh/

If still interested, please download the latest release from over there, read the ReadMe completely at least once, and follow all instructions all the way to the end.

In case an issue arises, please post it via the issues section over there.

This issue will now be closed.