DSDT Latitude E7450

[acquarius.13]

Hi crew,

 

even if this latitude is well covered by this forum, I tried to follow this guide for exercise, following also this thread to patch my DSDT.

 

I extracted it using F4 at clover boot options (r4644). In attachment I upload the origin folder and the errors I obtain. 

 

I've just started: I only tried to patch the DSDT.aml file

 

Can you please give me some hints?

 

Thanks,

 

Marco 

 

 

[viking1304]

1. Be sure that you can easily revert patched files that you got from Jake Lo

2. Go to preferences and add  http://raw.github.com/viking1304/E7450-DSDT-Patch/master to sources - that way you will not need to copy/paste syntax patch from here that Jake made. Name source as you like.

3. Click on Patch and apply [01][syn] Fix PARSEOP_IF/CLOSE_PAREN Errors from that new source (or manually copy/paste and apply fix)

4. Try to compile

5. If there is an error, click on that error, see lines which are causing the error and try to find appropriate patch from a list of [syn] patches in _RehabMan Laptop "folder"

6. Repeat until you successfully compile

7. Check other [syn] patches and see which one offer to patch something. Using those should be safe, but if anything fails, stick with those that are absolutely needed.

8. Now you are ready to start with real patching

9. Patch ONLY things that you ABSOLUTELY NEED, not everything you seen that can be patched

10. If you are brave enough, try to use your patched files, but be prepared to do what I wrote first

 

To be honest, I also just started researching this topic with similar goal as yours.

[Hervé]

Ok, this will be fairly easy...

 

-> 1st error shows: line 11613: syntax error, unexpected '}'

This is due to the line 11612 that contains only "Arg0"; it's incorrect and needs to be deleted

 

Once you've deleted that line, your DSDT should recompile Ok.

 

[viking1304]

I am trying to figure out what is actually needed to be patched for E7450 (with discrete nVidia 840) by comparing origin with patched files and also by comparing my patched files with patched files that I got. This is what I concluded so far.

 

Those patches are used in patched DSDT that I got:

 

[syn] Rename _DSM methods to XDSM

[sys] Fix _WAK Arg0 v2

[sys] HPET Fix

[sys] SMBUS Fix

[sys] IRQ Fix

[sys] RTC Fix

[sys] OS Check Fix (Windows

[sys] Fix Mutex with non-zero SyncLevel

[sys] Add IMEI

[sys] Add MCHC

[igpu] Rename GFX0 to IGPU

[igpu] Rename B0D3 to HDAU

[misc] Poll for LID changes misc/misc_LidPoll.txt

 

I guess that [usb] USB3 _PRW 0x6D (instant wake) is used too, but not sure yet (I still need to check that).

 

@Jake Lo would you mind to tell me what other patches have you used for E7450 (with discrete nVidia 840)?

 

Would you mind to explain few more thing that I am trying to understand?

 

1. Why have you added IMEI, when HECI was already there?

2. Why Fix PNOT/PPNT is not used when CpuSsdt and Cpu0Ist are dropped in config?

3. Are those references to ALC 293 (device-type in HDEF) and HD 5500 (model in IGPU) are really needed?

4. Why audio layout-id needs to be changed in DSTD, when it is injected (as 11) in Devices/Audio part of config? 

 

Am I missing something obvious?

 

[Jake Lo]

1) Because Rehabman don't have a patch to rename HECI to IMEI. I guess you could use Config file to do the renaming and leave out the patch, just preference I guess or use this patch

Quote

 

# rename HECI -> IMEI

into_all all label HECI set_label begin IMEI end;

 

2) You could apply it, I just don't see a difference with it applied. That said, I didn't start dropping CpuSsdt and Cpu0Ist until recent HS where it causes KP

3) No, just cosmetics in IOReg or in system information. Those can be applied via Config file

4) No need if you don't have layout-id defined in DSDT/SSDT.

 

Yes, [usb] USB3 _PRW 0x6D (instant wake)  is also being applied to fix sleep issue.

Might not need [misc] Poll for LID changes misc/misc_LidPoll anymore in HS, sleep with lid closed without it

 

To disable discrete nVidia 840

Apply [gfx0] Disable from _INI (SSDT) to SSDT-SgPch.dsl but you'll need to make modification from PEG0 to RP05 and uncomment out External declaration

Quote

into method label _INI parent_label \_SB.PCI0.RP05.PEGP insert
begin
//added to turn nvidia/radeon off\n
External(\_SB.PCI0.RP05.PEGP._OFF, MethodObj)\n
_OFF()\n
end;

and in DSDT, apply [gfx0] Disable/Enable on _WAK/_PTS (DSDT), again change PEG0 to RP05

 

 

Don't forget SDCard Reader patch

Quote

 

# into device label PXSX parent_label RP01 set_label begin PXSX end;
into_all method parent_label RP01 code_regex PXSX replaceall_matched begin PXSX end;

into device label PXSX insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "compatible", Buffer() { "pci14e4,16bc" },\n
        "name", Buffer() { "pci14e4,16bc" },\n
        "IOName", "pci14e4,16bc",\n
    })\n
}\n
end;

 

 

[viking1304]

Thank you very much Jake. I managed to patch and compile everything without any problem. I replaced old patched folder with new one and changed sort order in config to reflect new file names. As far as I can see, everything works as expected.

 

Since my main goal was to understand all this better, I have few more questions if you don't mind. 

 

Quote

1) Because Rehabman don't have a patch to rename HECI to IMEI. I guess you could use Config file to do the renaming and leave out the patch, just preference I guess or use this patch

 

That is very clear, but I am little confused about this info in patch itself:

# if you already have an IMEI/HECI/MEI device, you should not use this patch
# but if you do, these patches will remove the existing one

If I understand your point, IMEI is actually needed and this should be taken as "use only one of those 3, do not mix them".
 

Quote

 

2) You could apply it, I just don't see a difference with it applied. That said, I didn't start dropping CpuSsdt and Cpu0Ist until recent HS where it causes KP

 

 

 

As far as I understand, this remove methods which use some identifiers located in CPU SSDTs, so I guess you should not see any real difference. I applied this one.
 

Quote

 

4) No need if you don't have layout-id defined in DSDT/SSDT.

 

 

 

I am not sure I understood this. I need to change layout in patched files first in order to be able to use different layout in config later? I am not trying to avoid this, I am just trying to understand. Layout 11 works perfectly for me (especially with new AppleALC.kext).

 

When "Rename _DSM to XDSM" should be used? If you apply this one at the beginning, some other patches would add new _DSM methods later and those will not be renamed. Do I need to apply this one again at the end, or that should be avoided for some reason? 

 

Should I only add those definitions that are needed to fix some errors in refs.txt? If I add MDBG, there is no need to use Fix ADBG Error patch, since that error doesn't exist in that case.

 

Is there a way to add blank line (to make patched code cleaner, for easier compression with original? Adding just \n at the beginning of line doesn't work.

 

Thank you very much for your patience.

 

[Jake Lo]

Yes, if DSDT already has HECI or MEI, just rename it to IMEI.

What I mean about the layout-id in DSDT is that on some of my patches, I leave out that declaration so I could easily test different layout-ID with Config and not having to recompile DSDT. For example here, the highlighted strike through can be left out completely, also do the same for HDAU

Quote

into method label _DSM parent_label HDEF remove_entry;
into device label HDEF insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "layout-id", Buffer() { 3, 0x00, 0x00, 0x00 },\n
        "hda-gfx", Buffer() { "onboard-1" },\n
        "PinConfigurations", Buffer() { },\n
        //"MaximumBootBeepVolume", 77,\n
    })\n
}\n
end;

 

Do NOT re-apply "Rename _DSM to XDSM", that will defeat the purpose of patching the Devices like HDEF, EHC1, EHC2, XHC...etc

 

Yes, adding some external declaration will fix a lot of compiling errors, you could try decompiling with out refs.txt and see if it has more or less errors.

For Kabylake systems, you should avoid it, it'll generate more error than not.

 

You can add blank lines to your patches to make it look more readable but the compiler will determine how to format it.

Look at one of the patch I created, I could put it all in 1 liner and it'll still work the same, but it doesn't look good or easy to follow by the human eyes right?

Quote

# Fix IASL bug on some DSDT
into method label _CRS code_regex Store\s+\(Zero,\s+ECRW\s+\(If\s+\(PM0H\) replace_matched begin Store (Zero, ECRW) } If (PM0H) end;
into method label _CRS code_regex Store\s+\(Zero,\s+F0LN\)\s+?\}\)\) replace_matched begin Store (Zero, F0LN) end;

 

[viking1304]

Quote

Do NOT re-apply "Rename _DSM to XDSM", that will defeat the purpose of patching the Devices like HDEF, EHC1, EHC2, XHC...etc

 

I understand. It should be used before applying any patch that have _DSM method. Applying this patch again later would just make some new duplicate methods (but this time those methods would be called XDSM instead of _DSM) and it would be a new problem instead of a fix.

 

Patching of DSDT and disabling discrete nVidia in SgPch are now clear.

 

I am still not sure why some patches are applied on dropped tables. I guess because you didn't intended to drop those tables before some people reported problems (me among them). I guess I could delete those from patched folder since they are not used, right? I guess I could remove them from sort order too, or not?

 

btw. do you want me to send you my A19 origin so you can make new bootpack for people with A19 BIOS (even A17 bootpack works fine on A19)?

[Jake Lo]

Sure, that would be handy since I don't have a model with the nvidia graphics.

 

Yes, leave the dropped SSDT's out of the patched folder and sorted order as well.

[viking1304]

Here you go. I just made a fresh origin dump. SSDT-8-SgPch.aml and SSDT-x3_0-SgPch.aml are exactly the same (so now you know which table is blocking the dump if you use all of them).

 

Based on patched folders from different bootpacks I figured out that all tables that have x in name should not be used, but I can't find relevant info that explains why. To be honest I didn't check what is inside those tables, maybe the answer would came by itself.

 

I will remove dropped CPU tables from patched folder and sort order. I guess that I need to use all other SSDT tables (even those that are not patched, but without those with x) because Drop OEM will drop all original SSDTs.

 

 

E7450_A19_NV840_origin.zip