Contribute
Register

[solved] Asus UX310UA - installer disk util can't find the HDD

Status
Not open for further replies.
Dimitree said:
that's exactly what I've done.
only SSDT-2.aml and SSDT-3.aml have GFX0 references, along with DSDT.aml (used the command "grep -l GFX0 *.aml" on the "original" folder containing all the *.aml collected by Clover using F4)
so I applied the rename patch to DSDT and SSDT-2 and SSDT-3

so to recap:
- using my DSDT with "GFX0" and any SSDT inside "patched" folder -> boot ok
- using my DSDT with "IGPU" and any SSDT inside "patched" folder -> kernel panic (of course, renames must be balanced)
- using my DSDT with "GFX0" and SSDT-x.aml with "IGPU" inside "patched" folder -> boot ok
- using my DSDT with "IGPU" and SSDT-x.aml with "IGPU" inside "patched" folder -> kernel panic (attached screenshot)

seems like Clover isn't taking the SSDT-x.aml that I put inside the patched folder, but only the DSDT.aml, so when I use "IGPU" on the DSDT, it can't find the "IGPU" on the SSDTs.
or something else that I'm missing.

I'm attaching all the required by "Problem reporting".
Patched folder contains all the SSDT and DSDT that I'm using with renamed "IGPU" and that creates the kp
Click to expand...

Your ACPI configuration is wrong.
As per guide, DropOem must be true when you have patched SSDTs in ACPI/patched. You have it set false.
 
Dimitree said:
that's exactly what I've done.
only SSDT-2.aml and SSDT-3.aml have GFX0 references, along with DSDT.aml (used the command "grep -l GFX0 *.aml" on the "original" folder containing all the *.aml collected by Clover using F4)
so I applied the rename patch to DSDT and SSDT-2 and SSDT-3

so to recap:
- using my DSDT with "GFX0" and any SSDT inside "patched" folder -> boot ok
- using my DSDT with "IGPU" and any SSDT inside "patched" folder -> kernel panic (of course, renames must be balanced)
- using my DSDT with "GFX0" and SSDT-x.aml with "IGPU" inside "patched" folder -> boot ok
- using my DSDT with "IGPU" and SSDT-x.aml with "IGPU" inside "patched" folder -> kernel panic (attached screenshot)

seems like Clover isn't taking the SSDT-x.aml that I put inside the patched folder, but only the DSDT.aml, so when I use "IGPU" on the DSDT, it can't find the "IGPU" on the SSDTs.
or something else that I'm missing.

I'm attaching all the required by "Problem reporting".
Patched folder contains all the SSDT and DSDT that I'm using with renamed "IGPU" and that creates the kp
Click to expand...
SSDT-x.aml are not a "real" SSDT. Remove all SSDTs with -x.aml in the name.
 
HorchaudiBMW said:
SSDT-x.aml are not a "real" SSDT. Remove all SSDTs with -x.aml in the name.
Click to expand...

He has no dynamic SSDTs in ACPI/patched (post #60 attachment). Did you even look at EFI/Clover/ACPI/patched?
Main problem already identified in post #61.
 
Last edited:
right, DropOEM fixed that. Now it boots fine
I've read the DSDT patching guide, but it's not clear to me (mainly because of my bad english) if I should use or not "Fix PNOT/PPNT" now that I'm including the patched SSDT
 
RehabMan said:
He has no dynamic SSDTs in ACPI/patched (post #60 attachment). Did you even look at EFI/Clover/ACPI/patched?
Main problem already identified in post #61.
Click to expand...
No, I don´t saw the attachment from #60, because I post my reply with my smartphone.
I only saw the words "SSDT-x.aml" and wrote an answer, although he wrote in his post that SSDT-x.aml isn´t talking to Clover...
Just ignore my post...
 
Dimitree said:
right, DropOEM fixed that. Now it boots fine
I've read the DSDT patching guide, but it's not clear to me (mainly because of my bad english) if I should use or not "Fix PNOT/PPNT" now that I'm including the patched SSDT
Click to expand...

As per guide, the PNOT patch should only be used if you're dropping the CPU related SSDTs.
You have all the SSDTs in ACPI/patched, so it means you should not apply the PNOT patch.
 
HorchaudiBMW said:
No, I don´t saw the attachment from #60, because I post my reply with my smartphone.
I only saw the words "SSDT-x.aml" and wrote an answer, although he wrote in his post that SSDT-x.aml isn´t talking to Clover...
Just ignore my post...
Click to expand...

No worries. The OP wasn't referring to the SSDT-*x.aml files, but rather the non-dynamic SSDTs where 'x' was referred to as the digit there (eg. SSDT-0.aml, SSDT-1.aml, SSDT-2.aml, etc).
 
I am now trying to fix USB.
based on what I'm reading here: https://github.com/RehabMan/OS-X-USB-Inject-All
seems like I should have:
"100-series chipset (8086:9d2f): 10-USB2 ports HS01-HS10, 6-USB3 ports SS01-SS06"
but my IOreg shows that I have SS01 to SS10. Instead my laptop should have 2x USB2 and 1x USB3.0 and 1x USB3.1 (type C)
My USB ports are working if I connect USB devices, but as you said, maybe are not working at best.
My DSDT already have the patch "7-series/8-series USB" and "USB3 _PWR 0x6D Skylake (instant wake) that I applied when I started to patch my DSDT.
Do I still need to use USB-Inject-All?

my current problem report is on post #60,
https://www.tonymacx86.com/threads/...-cant-find-the-hdd.211767/page-6#post-1456164
 
Dimitree said:
I am now trying to fix USB.
based on what I'm reading here: https://github.com/RehabMan/OS-X-USB-Inject-All
seems like I should have:
"100-series chipset (8086:9d2f): 10-USB2 ports HS01-HS10, 6-USB3 ports SS01-SS06"
but my IOreg shows that I have SS01 to SS10. Instead my laptop should have 2x USB2 and 1x USB3.0 and 1x USB3.1 (type C)
My USB ports are working if I connect USB devices, but as you said, maybe are not working at best.
My DSDT already have the patch "7-series/8-series USB" and "USB3 _PWR 0x6D Skylake (instant wake) that I applied when I started to patch my DSDT.
Do I still need to use USB-Inject-All?

my current problem report is on post #60,
https://www.tonymacx86.com/threads/...-cant-find-the-hdd.211767/page-6#post-1456164
Click to expand...

https://www.tonymacx86.com/threads/guide-creating-a-custom-ssdt-for-usbinjectall-kext.211311/
 
thank you, I'm working on it, I'm waiting for a 3.1 type C USB adapter to plug a device in that port and discover it

in the meanwhile, trying to load AppleLPC.kext

When I started to patch my DSDT, the first patched I applied was remove _DSM methods, and then Skylake LPC.
But for some reason, after further patching to enable Audio e I2C touchpad, many _DSM methods appeared again and the Skylake LPC _DSM method disappeared.
So now I can't apply the Skylake LPC patch again since there are already many _DSM methods that create conflicts, and I can't remove them since are used by the I2C trackpad (indeed if I remove those methods, I can apply Skylake LPC but then I got KP because of I2C).
I also tried to rename them to XDSM, but same thing.

is there a way to add this method
Code: 
Method (_DSM, 4, NotSerialized)
                {
                    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
                    Return (Package()
                    {
                        "compatible", "pci8086,9cc1",
                    })
                }
inside the scope _SB / PCI0 / LPCB without removing other _DSM methods?
or an alternative without using DSDT patching?
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top