CloverHackyColor / CloverBootloader

Bootloader for macOS, Windows and Linux in UEFI and in legacy mode
BSD 2-Clause "Simplified" License
4.5k stars 618 forks source link

Clover r5122 breaks patching when target bridge data exists (works on r5119) #252

Closed mackonsti closed 3 years ago

mackonsti commented 3 years ago

Hi everyone, this bug seems to exist (or crawl back) in Clover r5122 unfortunately, preventing me to boot Catalina. Can you please have a look? Here are my parameters.

In my config.plist I replace a Method in a Device:

                <dict>
                    <key>Comment</key>
                    <string>Rename _STA to XSTA in H_EC</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>
                    X1NUQQ==
                    </data>
                    <key>Replace</key>
                    <data>
                    WFNUQQ==
                    </data>
                    <key>TgtBridge</key>
                    <data>
                    SF9FQw==
                    </data>
                </dict>

...so I can inject SSDT-EC-USBX.aml and disable (via _STA) the original device H_EC and add a fake EC device needed for Catalina. But in my IORegistryExplorer I see this didn't work. Here is Clover log via Hackintool:

1:472  0:000   - [11]: (Rename _STA to XSTA in H_EC) lenToFind: 4, lenToReplace: 4, Target Bridge: H_ECtptalÉt0
1:472  0:000   - [12]: (Fix NUC BIOS RTC Device) lenToFind: 8, lenToReplace: 8, Target Bridge: 
1:472  0:000    patch disabled at config
...
5:438  0:000   - [Rename XHC_ to XHC1]: disabled
5:438  0:000   - [Rename _STA to XSTA in H_EC]:ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6

As @SergeySlice said in the InsanelyMac thread, this results in endless lines. I was under the impression this was fixed by @SergeySlice commit earlier on, can someone please confirm and assist?

Bug seems to be when parsing the data of the target bridge :-(

I just found out when trying to get Catalina on my Mojave after updating everything (Clover, Acidanthera's kexts etc.). This seems to have broken in r5122 as I was able to boot with some USB key with r5119 and it works fine.

Many thanks!

stevezhengshiqi commented 3 years ago

I can confirm this issue. H_EC is recognized as something like H_EC'# in my case. Its length exceeds 4 so it can't pass the check. I believe it's https://github.com/CloverHackyColor/CloverBootloader/commit/e9f0f8ccd84d31c1aeacc5eed862e91f82ea3d18#diff-759fbc4d1498d5ceee8eb9a5eced3907 causing this issue. TgtBridge should be handled in the same way as Find and Replace as an XBuffer<UINT8>, instead of XString8&.

I didn't have a deeper look at how XBuffer and XString are defined. Please correct me if I am wrong. CC @jief666

UPDATE: Sorry that I misunderstand some code, TgtBridge should be CHAR8* so it's reasonable that it uses XString.

jief666 commented 3 years ago

Yes, exactly. I've corrected it 8 hours ago and send you a Clover efi to test in this post : https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?do=findComment&comment=2739566

I believe it's e9f0f8c#diff-759fbc4d1498d5ceee8eb9a5eced3907 causing this issue. TgtBridge should be handled in the same way as Find and Replace as an XBuffer, instead of XString8&.

You are exactly right.

jief666 commented 3 years ago

Could you test this : CloverX64-2020-10-04 00:06:31 +0300-Clover revision: 5123-jief-0710.1.zip before I commit ?

stevezhengshiqi commented 3 years ago

Stuck at here, can't verify whether tgtbridge works or not. Someone who can boot with r5123 is welcome to test tgtbridge. IMG_3061

jief666 commented 3 years ago

We could see it in your debug.log. Did you activate config.plist/Boot/Debug ?

stevezhengshiqi commented 3 years ago

Seems not work. It keeps looping ATTENTION : CmpDev called with a H_ECÿ with length() != 4 5 debug.log

I am too lazy to change my H_EC patch comment, it should be - [Rename Method(_UPC,0,S) to XUPC, pair with SSDT-USB.aml (USB Port Customization)]:ATTENTION : CmpDev called with a H_ECÿ with length() != 4 5 in the log.

jief666 commented 3 years ago

Could you send me your config.plist ?

stevezhengshiqi commented 3 years ago

Sure. config.plist.zip

bfitzgit23 commented 3 years ago

can i attach my config also jief? i also tried your commit of clover too on my dell inspiron 7567 laptop it wont boot catalina 10.15.7 or big sur beta 9.

jief666 commented 3 years ago

Found something. This one : CloverX64-2020-10-06 23:02:14 +0300-Clover revision: 5123-jief-0710.2.zip ?

@bfitzgit23 : this thread is for this issue, which is about "patching when target bridge data exists". Go to forum first (https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?page=943). Your config.plist cannot be enough to diagnose anything. I don't have the same hardware as you.

bfitzgit23 commented 3 years ago

well nobody did there either, i only found github pages and they've not updated their EFIs to big sur yet..so im unsure how to best proceed..

stevezhengshiqi commented 3 years ago

@jief666 debug.log correctly shows H_EC this time. Thank you so much!

jief666 commented 3 years ago

Ok. I'll commit in a sec.

jief666 commented 3 years ago

@bfitzgit23 I forgot your post, but maybe you weren't specific enough ? If you say here is my hardware, here is my debug.log and I'm blocked at this point, you'll get more answer. I'll personally help when a Clover bug is identified.

bfitzgit23 commented 3 years ago

ok ill test with the commit you're about to do and if i run into issues, ill write back with hardware, debug.log, etc.

mackonsti commented 3 years ago

Hi everyone, thanks for your feedback, thanks @jief666 for your quick fix. I am at work and cannot test. Am I right to assume that this fix will be officially present in r5124 then? Thank you (just to know to not bother with r5122 or r5123 really).

jief666 commented 3 years ago

I'm not taking care of revision. My understanding is that everything committed will be present is the next release. So my guess is yes, it'll be in 5124.