Contribute
Register

Yet another Lenovo G50-70 install Mavericks thread

Status
Not open for further replies.
There is a patch in my repo for those errors. Hint: the fix is to remove them.
Thanks. Maybe I'll muster the energy before I go out to take a quick peek, as I'm sure that this will bug me all night and I'll be back at it in the morning.

Here's a raw dump of what I pulled using acpidump & extract.
 

Attachments

  • acpi.zip
    139.8 KB · Views: 73
There is a patch in my repo for those errors. Hint: the fix is to remove them.
Yeah, "fixed" those, but my question is, is t hat REALLY a fix or does it just work for what we have? i.e. had you tried my proposed fix as well?

I tried to send you a PM but apparently I'm not a prolific enough(75 posts) poster to send you one in which I wanted to discuss ACPI matters.

That said when I tried your fixes I did it on the desktop and popped another compile error(which I don't have at hand ATM) along with the two fixes that you(commenting them out?!) have. I'm not entirely happy with that solution.

What is your confidence that the decompiler is decompiling correctly?

[EDIT]
My gut feeling on this is that it's pretty low with complex structures...
[/EDIT]

[EDIT2]
I'm pretty much asking as using the archive attached on the desktop I popped a third compile error, and as alluded to above I have SERIOUS RESERVATIONS about the correctness of the decompiler other than in the most simplistic cases...
[/EDIT2]
 
more to the point I'm getting:
Code:
68, 6074, Name already exists in scope (_SB_.PCI0.RP05.PEGP)
along with the prior two PARSEOP_STORE errors that I was getting on compile on the notebook itself...*

* I'm doing this on my hackintosh desktop ATM as it's just so much faster...
 
I'm not planning on doing anything tonight much, but wouldn't mind your comments if you're available to do so...

I'll try this again on the g50 and see what I get, as I was surprised by the dup error(above), but...**

** like I mentioned I have my doubts on the correctness of the decompiler, let alone the compiler

[EDIT]
...and yeah my hdd caddy ca me but they shipped the wrong one, a 12.7mm rather than the 9.5mm ordered... bleh...
[/EDIT]

[EDIT2]
...same dup ident error on the g50 now... I could have sworn that Friday all I had were those parseopstore errors, but I was getting really tired and then trying on the desktop popped the dup error as well...

I still really DOUBT the CORRECTNESS of the decompiler AND compiler...
[/EDIT2]
 
Yeah, "fixed" those, but my question is, is t hat REALLY a fix or does it just work for what we have? i.e. had you tried my proposed fix as well?

That is the fix. There tends to be code that is specific to Windows that we just remove...

That said when I tried your fixes I did it on the desktop and popped another compile error(which I don't have at hand ATM) along with the two fixes that you(commenting them out?!) have. I'm not entirely happy with that solution.

Yes... it is common with compilers that fixing one error will reveal others that were ignored before.

What is your confidence that the decompiler is decompiling correctly?

It works, but disassembly is never perfect.
 
more to the point I'm getting:
Code:
68, 6074, Name already exists in scope (_SB_.PCI0.RP05.PEGP)
along with the prior two PARSEOP_STORE errors that I was getting on compile on the notebook itself...*

* I'm doing this on my hackintosh desktop ATM as it's just so much faster...

It is a common error. I believe it is an iasl bug.
 
Well, I've started working up a patch for the battery after checking all the available patches, thinking that a notebook from the same mfg was mostly likely to have copy-and-pasteitess along with similar/same chips used, but alas it wasn't so, so base on http://www.tonymacx86.com/yosemite-...de-how-patch-dsdt-working-battery-status.html I started with this(not very far doing on hackbook):
Code:
// start lenovo g50-70 patch
//
// 
// 
//                        FWBT,   64, 
//                        SMDA,   256, 
//                        BMN0,   72,  *NOT USED*
//                        BDN0,   56,  *NOT USED*
//                        B1RC,   16,  BRC0 8, BRC1 8
//                        B1SN,   16,  *NOT USED*
//                        B1FV,   16,  BFV0 8, BFV1 8
//                        B1DV,   16,  BDV0 8, BDV1 8
//                        B1DC,   16,  BDC0 8, BDC1 8
//                        B1FC,   16,  BFC0 8, BFC1 8
//                        B1CR,   16,  *NOT USED*
//                        B1AC,   16,  BAC0 8, BAC1 8
//                        B1CC,   16,  *NOT USED*
//                        B1SM,   16,  *NOT USED*
//                        B1C1,   16,  *NOT USED*
//                        B1C2,   16,  *NOT USED*
//                        B1C3,   16,  *NOT USED*
//                        B1C4,   16,  *NOT USED*
into device label H_EC code_regex B1RC,\s+16, replace_matched begin BRC0,8,BRC1,8, end;
into device label H_EC code_regex B1FV,\s+16, replace_matched begin BFV0,8,BFV1,8, end;
into device label H_EC code_regex B1DV,\s+16, replace_matched begin BDV0,8,BDV1,8, end;
into device label H_EC code_regex B1DC,\s+16, replace_matched begin BDC0,8,BDC1,8, end;
into device label H_EC code_regex B1FC,\s+16, replace_matched begin BFC0,8,BFC1,8, end;
into device label H_EC code_regex B1AC,\s+16, replace_matched begin BAC0,8,BAC1,8, end;
//
into method label B1B2 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }\n
end;
//
into method label GBTI code_regex \(B1RC, replaceall_matched begin (B1B2(BRC0,BRC1), end;
My only real concern are the SMDA fields as it's read from and written to, and just is the entire block.
Code:
                    OperationRegion (ERAM, EmbeddedControl, Zero, 0xFF)
                    Field (ERAM, ByteAcc, Lock, Preserve)
                    {
                        VCMD,   8, 
                        ...
                        SMDA,   256, 
                        ...
                    }

...
                                        If (LEqual (And (Local0, One), Zero))
                                        {
                                            Store (FB4, SMDA)
                                        }
...

                                        If (LNotEqual (And (Local0, One), Zero))
                                        {
                                            Store (SMDA, FB4)
                                        }
...
Admittedly I haven't attempted to track down DSDTs from other machines to see how similar >32b fields were used, and TBH I'm not at all certain wrt B1B2 method, and subsequent match/replacements.

But does this seem like a good start or am I entirely wrong?

(Still need to read more about clove config as I'm not entirely certain that my patched* dsdt/ssdt are being loaded.

*patched for GFX0 -> IGPU (dsdt, ssdt4) and
Brightness patch(Haswell) (ssdt4)

I've got them compiling with no errors and have dumped the dsdt/ssdt into /EFI/EFI/CLOVER/ACPI/patched as:
DSDT.aml and SSDT.aml (is it necessary to use IIRC ssdtprgen.sh script to generate a base SSDT?)
 
Well, I've started working up a patch for the battery after checking all the available patches, thinking that a notebook from the same mfg was mostly likely to have copy-and-pasteitess along with similar/same chips used, but alas it wasn't so, so base on http://www.tonymacx86.com/yosemite-...de-how-patch-dsdt-working-battery-status.html I started with this(not very far doing on hackbook):
Code:
// start lenovo g50-70 patch
//
// 
// 
//                        FWBT,   64, 
//                        SMDA,   256, 
//                        BMN0,   72,  *NOT USED*
//                        BDN0,   56,  *NOT USED*
//                        B1RC,   16,  BRC0 8, BRC1 8
//                        B1SN,   16,  *NOT USED*
//                        B1FV,   16,  BFV0 8, BFV1 8
//                        B1DV,   16,  BDV0 8, BDV1 8
//                        B1DC,   16,  BDC0 8, BDC1 8
//                        B1FC,   16,  BFC0 8, BFC1 8
//                        B1CR,   16,  *NOT USED*
//                        B1AC,   16,  BAC0 8, BAC1 8
//                        B1CC,   16,  *NOT USED*
//                        B1SM,   16,  *NOT USED*
//                        B1C1,   16,  *NOT USED*
//                        B1C2,   16,  *NOT USED*
//                        B1C3,   16,  *NOT USED*
//                        B1C4,   16,  *NOT USED*
into device label H_EC code_regex B1RC,\s+16, replace_matched begin BRC0,8,BRC1,8, end;
into device label H_EC code_regex B1FV,\s+16, replace_matched begin BFV0,8,BFV1,8, end;
into device label H_EC code_regex B1DV,\s+16, replace_matched begin BDV0,8,BDV1,8, end;
into device label H_EC code_regex B1DC,\s+16, replace_matched begin BDC0,8,BDC1,8, end;
into device label H_EC code_regex B1FC,\s+16, replace_matched begin BFC0,8,BFC1,8, end;
into device label H_EC code_regex B1AC,\s+16, replace_matched begin BAC0,8,BAC1,8, end;
//
into method label B1B2 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }\n
end;
//
into method label GBTI code_regex \(B1RC, replaceall_matched begin (B1B2(BRC0,BRC1), end;
My only real concern are the SMDA fields as it's read from and written to, and just is the entire block.
Code:
                    OperationRegion (ERAM, EmbeddedControl, Zero, 0xFF)
                    Field (ERAM, ByteAcc, Lock, Preserve)
                    {
                        VCMD,   8, 
                        ...
                        SMDA,   256, 
                        ...
                    }

...
                                        If (LEqual (And (Local0, One), Zero))
                                        {
                                            Store (FB4, SMDA)
                                        }
...

                                        If (LNotEqual (And (Local0, One), Zero))
                                        {
                                            Store (SMDA, FB4)
                                        }
...
Admittedly I haven't attempted to track down DSDTs from other machines to see how similar >32b fields were used, and TBH I'm not at all certain wrt B1B2 method, and subsequent match/replacements.

But does this seem like a good start or am I entirely wrong?

You're on the right track. There are plenty of examples (DSDT patches already in the repo using RECB/WECB) of r/w EC buffer fields...

(Still need to read more about clove config as I'm not entirely certain that my patched* dsdt/ssdt are being loaded.

*patched for GFX0 -> IGPU (dsdt, ssdt4) and
Brightness patch(Haswell) (ssdt4)

I've got them compiling with no errors and have dumped the dsdt/ssdt into /EFI/EFI/CLOVER/ACPI/patched as:
DSDT.aml and SSDT.aml (is it necessary to use IIRC ssdtprgen.sh script to generate a base SSDT?)

DSDT.aml and SSDT.aml will certainly be loaded. But unless you use DropOem=true, OEM SSDTs will load before any SSDTs from ACPI/patched, such that your patched ones are likely ignored by OS X. Also, it is best to avoid confusion and keep the original numbers... eg. ACPI/patched/SSDT-4.aml. And that way when you generate an SSDT for your CPU it can go at ACPI/patched/SSDT.aml.
 
DSDT.aml and SSDT.aml will certainly be loaded. But unless you use DropOem=true, OEM SSDTs will load before any SSDTs from ACPI/patched, such that your patched ones are likely ignored by OS X. Also, it is best to avoid confusion and keep the original numbers... eg. ACPI/patched/SSDT-4.aml. And that way when you generate an SSDT for your CPU it can go at ACPI/patched/SSDT.aml.
I switched back to the desktop to send these, but I believe that I already did set DropOEM=true.

Numbering:
I did NOT know that. I figured that it was dumb and only went to e.g. SSDT-1 IFF SSDT.aml existed, and -2 ONLY IFF SSDT-1 existed, etc. so yeah, I will change that.

In the case of patching, then the Haswell brightness fix appears to not be working for me. I'll check it again later as my correct sized caddy is supposed to be here today, and OSX drive -> caddy, and org OEM drive back to where it's supposed to be instead of sitting in a box looking sad... :D

Thanks again for the help, of course I'll probably come back to bug you about how exactly to turn the patch into a REAL patch that I can load/apply in maciasl(using v1.2 as IIRC it was the newest that I could find and IIRC was dependent upon 10.8(or older) SDK which I don't have and don't want mess around with setting up ATM...)
 
Status
Not open for further replies.
Back
Top