[SOLVED] Battery SSDT not working after bios update

[BlvckBytes]

@tyraenor

Happy to see that you want to learn about the topic. I can't say for sure that I know about all of your mistakes, since I haven't combed through all of your SSDT, but I can say the following:

Your renames look promising and correct. You seem to use a hex-editor like HexFiend (or similar), and all of the replaces start with 14 (OP-Code for Method). For some reason (and I don't know why, sadly) the GBTI rename (14454247 42544901) did not apply. Since the bytes after 14 are the method-signature and length, I guess that something changed around there. I couldn't compile your SystemDSDT because of errors, which is why I couldn't check if something changed. I just used another sequence (47425449 01700D45) which is basically unique, since it includes a part of the debug comment right after the method declaration.

Another mistake I've seen: You can't use B1B2 or B1B4 to assign variable values. You need to use WECB(offset, length-in-bits, value), one of RehabMans utility-methods.

Oh, and btw, you should not just copy the whole region and change up some of the fields. In an ideal situation, only the patched fields should go into the SSDT. This does require you to calculate the absolute offsets for all fields, and then put Offset-instructions where there are gaps.

I am currently working on a tool, which is far from being complete, but it is able to generate the Region-patch so far. Also used that on your case, since it saves time and provides helpful comments with former name and absolute offset.

GitHub - BlvckBytes/ECPatcher: Tool to automatically patch the EmbeddedControl Operation-Regions in a DSDT to be macOS-compatible

Tool to automatically patch the EmbeddedControl Operation-Regions in a DSDT to be macOS-compatible - BlvckBytes/ECPatcher

github.com

 

[tyraenor]

@tyraenor

Happy to see that you want to learn about the topic. I can't say for sure that I know about all of your mistakes, since I haven't combed through all of your SSDT, but I can say the following:

Your renames look promising and correct. You seem to use a hex-editor like HexFiend (or similar), and all of the replaces start with 14 (OP-Code for Method). For some reason (and I don't know why, sadly) the GBTI rename (14454247 42544901) did not apply. Since the bytes after 14 are the method-signature and length, I guess that something changed around there. I couldn't compile your SystemDSDT because of errors, which is why I couldn't check if something changed. I just used another sequence (47425449 01700D45) which is basically unique, since it includes a part of the debug comment right after the method declaration.

Another mistake I've seen: You can't use B1B2 or B1B4 to assign variable values. You need to use WECB(offset, length-in-bits, value), one of RehabMans utility-methods.

Oh, and btw, you should not just copy the whole region and change up some of the fields. In an ideal situation, only the patched fields should go into the SSDT. This does require you to calculate the absolute offsets for all fields, and then put Offset-instructions where there are gaps.

I am currently working on a tool, which is far from being complete, but it is able to generate the Region-patch so far. Also used that on your case, since it saves time and provides helpful comments with former name and absolute offset.

GitHub - BlvckBytes/ECPatcher: Tool to automatically patch the EmbeddedControl Operation-Regions in a DSDT to be macOS-compatible

Tool to automatically patch the EmbeddedControl Operation-Regions in a DSDT to be macOS-compatible - BlvckBytes/ECPatcher

github.com

Oh and by the way, should I try to fix all the compiling errors of my System DSDT, I mean is that even possible?

 

[BlvckBytes]

@tyraenor

First off, have I just encountered a bug on this forum, or has your previous response been deleted? Anyways, I still have it cached on my phone, which is why I'm able to respond anyways.

Yep, I'm from austria, . I'd love to wish you a good night and give greetings in German too, but since i just saw that it's against the rules, and I have to assume that your post was deleted because of that, I'll have to suppress that, .

Anyways... Yep, WECB just writes byte by byte into the Region. Just to make this clear to you, have a quick look:

// Arg0: Offset, Arg1: Length in bits, Arg2: Value
Method (WECB, 3, Serialized)
{
        Arg1 >>= 0x03
        Name (TEMP, Buffer (Arg1){})
        TEMP = Arg2
        Arg1 += Arg0
    Local0 = Zero
    While ((Arg0 < Arg1))
    {
        WE1B (Arg0, DerefOf (TEMP [Local0]))
        Arg0++
        Local0++
    }
}

// Arg0: Offset, Arg1: Value
Method (WE1B, 2, NotSerialized)
{
    OperationRegion (ERAM, EmbeddedControl, Arg0, One)
    Field (ERAM, ByteAcc, NoLock, Preserve)
    {
        BYTE,   8
    }
    BYTE = Arg1
}

WE1B basically stands for write EC 1 byte, which just creates a new region, new field, new fieldunit of 8 bits in length, and then assigns that value. Looks crude, but works. WECB used WE1B as a subroutine to write the bigger value byte by byte. Arg0 gets incremented (++) for each iteration, which is already in bytes, and Arg2 gets shifted until all bits have been written.

I just name the region EPCH, standing for EC-Patch. It's irrelevant what you call it, just try to keep the name collision-free.

If you have any questions, you can always ask ahead, I love to spread the little knowledge I have, so more people get aware of the process and can contribute to hackintoshing being more successful and easier to accomplish.

 

[BlvckBytes]

Oh and by the way, should I try to fix all the compiling errors of my System DSDT, I mean is that even possible?

Nope, those are not even real errors, afaik. ACPI has to compile, since OC needs to re-calculate the files checksum after altering it. If you patch in something that can't evaluate to valid code, OC halts.

But in assembling/deassembling - especially if you try to extract it from the OS - some translation-errors occur. Just leave it as it is, it's good enough for investigation. Btw, as you might have noticed: When you try to apply search/replace instructions, you can use MaciASL in a booted session and search for your replaced names, to check and see if they have been applied correctly (like, if at all and if only once - at the method-definition).

 

[tyraenor]

@tyraenor

First off, have I just encountered a bug on this forum, or has your previous response been deleted? Anyways, I still have it cached on my phone, which is why I'm able to respond anyways.

Yep, I'm from austria, . I'd love to wish you a good night and give greetings in German too, but since i just saw that it's against the rules, and I have to assume that your post was deleted because of that, I'll have to suppress that, .

Anyways... Yep, WECB just writes byte by byte into the Region. Just to make this clear to you, have a quick look:

// Arg0: Offset, Arg1: Length in bits, Arg2: Value
Method (WECB, 3, Serialized)
{
        Arg1 >>= 0x03
        Name (TEMP, Buffer (Arg1){})
        TEMP = Arg2
        Arg1 += Arg0
    Local0 = Zero
    While ((Arg0 < Arg1))
    {
        WE1B (Arg0, DerefOf (TEMP [Local0]))
        Arg0++
        Local0++
    }
}

// Arg0: Offset, Arg1: Value
Method (WE1B, 2, NotSerialized)
{
    OperationRegion (ERAM, EmbeddedControl, Arg0, One)
    Field (ERAM, ByteAcc, NoLock, Preserve)
    {
        BYTE,   8
    }
    BYTE = Arg1
}

WE1B basically stands for write EC 1 byte, which just creates a new region, new field, new fieldunit of 8 bits in length, and then assigns that value. Looks crude, but works. WECB used WE1B as a subroutine to write the bigger value byte by byte. Arg0 gets incremented (++) for each iteration, which is already in bytes, and Arg2 gets shifted until all bits have been written.

I just name the region EPCH, standing for EC-Patch. It's irrelevant what you call it, just try to keep the name collision-free.

If you have any questions, you can always ask ahead, I love to spread the little knowledge I have, so more people get aware of the process and can contribute to hackintoshing being more successful and easier to accomplish.

Hmm... I do not get why it is against the rules, especially when it is just two sentences... But okay.

Thanks for the clarification, I think with a bit investigation I will fully understand that, so thank you very much for sharing and explaining.

 

[Feartech]

Hmm... I do not get why it is against the rules, especially when it is just two sentences... But okay.

Thanks for the clarification, I think with a bit investigation I will fully understand that, so thank you very much for sharing and explaining.

• All posts must be made in English. Any and all posts in other languages will be deleted.

Terms and rules

You must agree to these terms and rules before using the site.

www.tonymacx86.com

 

[tyraenor]

Nope, those are not even real errors, afaik. ACPI has to compile, since OC needs to re-calculate the files checksum after altering it. If you patch in something that can't evaluate to valid code, OC halts.

But in assembling/deassembling - especially if you try to extract it from the OS - some translation-errors occur. Just leave it as it is, it's good enough for investigation. Btw, as you might have noticed: When you try to apply search/replace instructions, you can use MaciASL in a booted session and search for your replaced names, to check and see if they have been applied correctly (like, if at all and if only once - at the method-definition).

Okay. I will ignore these errors then.

Yes I did that, but I did not check all, as I thought - in my naive thinking - that if I check one or two, then the other will have worked, too. What a fool I was... ;-)

 

[tyraenor]

• All posts must be made in English. Any and all posts in other languages will be deleted.

Terms and rules

You must agree to these terms and rules before using the site.

www.tonymacx86.com

I saw this, but I - foolishly - assumed that the whole post was meant. That is why I wrote the explanation in my post. But it's okay. Now I know the exact meaning of this rule.

Thanks.

 

[tyraenor]

@BlvckBytes one off-topic question: I saw your VoodooRMI project on GitHub, is this a thing which is worth trying? I mean ForceTouch emulation sound neat.

 

[tyraenor]

That means, now I have a flawlessly working HackBookPro, just one thing remains... If I reboot after the system was at sleep and woke up, I get an RTC error on boot. I hope I find a way to fix this, because then it is perfect.