HP Elitebook Folio 1020 and DW1820a

[livacore]

You can use a USB (prepared according to my guide) to boot with "native enough" ACPI.

Remove whole ACPI key in plist.

 

[RehabMan]

Remove whole ACPI key in plist.

That will not result in a clean ACPI.
Also, it is not what you have in your files.
Please see the guide for correct USB preparation.

 

[livacore]

That will not result in a clean ACPI.
Also, it is not what you have in your files.
Please see the guide for correct USB preparation.

Sorry for my mis understand. Now using config from your OS-X-Clover-Laptop-Config.
It seems no patch version load all ACPI except dynamic SSDT.

 

[RehabMan]

Sorry for my mis understand. Now using config from your OS-X-Clover-Laptop-Config.
It seems no patch version load all ACPI except dynamic SSDT.

Ok, now patch DSDT.aml only as follows.. remove PXSX under RP04. This code to be removed:

                Device (PXSX)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                    Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                    {
                        Return (GPRW (0x69, 0x04))
                    }

                    Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
                    {
                        Return (HPCE)
                    }
                }

Then try to boot with vanilla IO80211Family..

And probably you should try a test where you remove only the _RMV method...

 

[livacore]

Ok, now patch DSDT.aml only as follows.. remove PXSX under RP04. This code to be removed:

                Device (PXSX)
                {
                }

Then try to boot with vanilla IO80211Family..

And probably you should try a test where you remove only the _RMV method...

Sorry man, English is not my primary language. I'm sorry if I post wrong words, wrong grammar....
There are two test target of mine: ECS liva core, HP Elitebook 1020 G1.
But, the kernel panic happens on HP Elitebook 1020 G1, not ECS liva core. The code you post seems extract from ECS liva core which do not have panic, it is works fine. (I post ACPI of ECS liva core is just to compare why a wifi device can work for one PC, but not another. It is just use to see what different they are.)

Sorry, if I do some wrong thing. The problem device (HP Elitebook 1020 G1) has a WNIC device under RP04.

Sorry.

 

[RehabMan]

But, the kernel panic happens on HP Elitebook 1020 G1, not ECS liva core. The code you post seems extract from ECS liva core which do not have panic, it is works fine.

It is from the files you provided.
I don't know why you would provide files from another computer.
If you have different files to show, please do so.

 

[livacore]

It is from the files you provided.
I don't know why you would provide files from another computer.
If you have different files to show, please do so.

Post #23 do not have PXSX under RP04....

There two dir, patched and no_patch, which contains file reflect status when booting from corresponding resources as its name.
Native APCI files in patched/CLOVER/ACPI/origin. Hope do not confuse you...

 

[RehabMan]

Post #23 do not have PXSX under RP04....

You're being too confusing with too many files, from different computers.
Remove the entire Device leaf node that is associated with the WiFi device.
Then test.

In this set, the WiFi device is at _SB.PCI0.RP04.WNIC.
There are no files in ACPI/origin (in no_patch), so I went off patchmatic output.
Try removing all this code from DSDT:

                Device (WNIC)
                {
                    Name (_ADR, 0x00)  // _ADR: Address
                    OperationRegion (FLDR, PCI_Config, 0x44, 0x06)
                    Field (FLDR, ByteAcc, NoLock, Preserve)
                    {
                        DCAP,   32, 
                        DCTR,   16
                    }

                    Method (_PRW, 0, Serialized)  // _PRW: Power Resources for Wake
                    {
                        Return (^^_PRW)
                    }

                    Method (_PLD, 0, Serialized)  // _PLD: Physical Location of Device
                    {
                        Return (EPLD)
                    }

                    Name (SPLC, Package (0x02)
                    {
                        0x00, 
                        Package (0x03)
                        {
                            0x07, 
                            0x0834, 
                            0x7530
                        }
                    })
                    PowerResource (WRST, 0x05, 0x0000)
                    {
                        Method (_STA, 0, NotSerialized)  // _STA: Status
                        {
                            Return (0x01)
                        }

                        Method (_ON, 0, NotSerialized)  // _ON_: Power On
                        {
                        }

                        Method (_OFF, 0, NotSerialized)  // _OFF: Power Off
                        {
                        }

                        Method (_RST, 0, NotSerialized)  // _RST: Device Reset
                        {
                            If ((DCAP & 0x10000000))
                            {
                                Local0 = DCTR
                                Local0 |= 0x8000
                                DCTR = Local0
                            }
                        }
                    }

                    Name (_PRR, Package (0x01)  // _PRR: Power Resource for Reset
                    {
                        WRST
                    })
                }

That should leave you with a leaf node in ioreg of pci14e4,43a3 instead of WNIC (eg. disconnected from all ACPI code).
Then you can restore vanilla IO80211Family.kext and test.

 

[livacore]

Then you can restore vanilla IO80211Family.kext and test.

Does vanilla mean remove those Brcm4360 patches?

Before test, I think there is some thing to confirm. I will extract origin ACPI, disassemble aml, fix errors, then using your version of iasl to compile it:

$ iasl *.dsl

As discussed in `Patching LAPTOP DSDT/SSDTs' thread, due to binary aml code change from original ACPI.

<string>change LANC Method(_PRW,0,Serialized) to Method(XPRW,0,..)</string>
$ echo AAAZABQfX1BSVwg= | base64 -D | xxd -p
00001900141f5f50525708
$ echo AAAZABQdX1BSVwg= | base64 -D | xxd -p
00001900141d5f50525708

Look `141f' in OEM ACPI, but `141d' in the file compiled by your version of iasl.

<string>change EC Method(_REG,2,N) to XREG, 4x40s, 4x30s</string>
$ echo X1JFRwKgKJNoCgM= | base64 -D | xxd -p
5f52454702a02893680a03
$ echo X1JFRwKgJZNoCgM= | base64 -D | xxd -p
5f52454702a02593680a03

The same in this patch, `2893' change to `2593'.

Is it necessary to change the patch corresponding to new binary aml code?

 

[RehabMan]

Does vanilla mean remove those Brcm4360 patches?

Which Brcm4360 patches are you referring to?

Before test, I think there is some thing to confirm. I will extract origin ACPI, disassemble aml, fix errors, then using your version of iasl to compile it:

$ iasl *.dsl

As discussed in `Patching LAPTOP DSDT/SSDTs' thread, due to binary aml code change from original ACPI.

<string>change LANC Method(_PRW,0,Serialized) to Method(XPRW,0,..)</string>
$ echo AAAZABQfX1BSVwg= | base64 -D | xxd -p
00001900141f5f50525708
$ echo AAAZABQdX1BSVwg= | base64 -D | xxd -p
00001900141d5f50525708

Look `141f' in OEM ACPI, but `141d' in the file compiled by your version of iasl.

<string>change EC Method(_REG,2,N) to XREG, 4x40s, 4x30s</string>
$ echo X1JFRwKgKJNoCgM= | base64 -D | xxd -p
5f52454702a02893680a03
$ echo X1JFRwKgJZNoCgM= | base64 -D | xxd -p
5f52454702a02593680a03

The same in this patch, `2893' change to `2593'.

Is it necessary to change the patch corresponding to new binary aml code?

Using a newer iasl to recompile files can result in different binary code due to new iasl compiler optimizations.