jalavoui Posted Saturday at 10:33 PM Share Posted Saturday at 10:33 PM (edited) omg that is why it is not working. give me a sec dont delete your current code k try start with this. fix the card id in info.plist try in debug release i got some ideas but need to see logs NootedBlue-master.zip Edited Saturday at 10:46 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Saturday at 11:40 PM Author Share Posted Saturday at 11:40 PM (edited) To avoid the collection of kp encountered I MUST enable these solving requests in order in the code you pass (that stalls to me), this is the minimal setup {"__ZN19AppleIntelPowerWell4initEP24AppleIntelBaseController",releaseDoorbell}, {"__ZN31AppleIntelRegisterAccessManager14ReadRegister32Em",raReadRegister32, this->oraReadRegister32}, {"__ZN19AppleIntelPowerWell19enableDisplayEngineEv",releaseDoorbell}, {"__ZN19AppleIntelPowerWell21hwSetPowerWellStatePGEbj",releaseDoorbell}, {"__ZN19AppleIntelPowerWell20disableDisplayEngineEv",releaseDoorbell}, {"__ZN19AppleIntelPowerWell22hwSetPowerWellStateAuxEbj",releaseDoorbell}, Then can finally boot without kp (but only mouse in video) and have finally logs (attached below) x.log.zip Kernel-2024-11-10-000338.panic Kernel-2024-11-10-001043.panic Kernel-2024-11-10-001627.panic Kernel-2024-11-10-002134.panic Kernel-2024-11-10-002712.panic kern_gen11.cpp Edited Saturday at 11:43 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Saturday at 11:42 PM Share Posted Saturday at 11:42 PM (edited) k checking log is perfect except for this because of this {"__ZN19AppleIntelPowerWell4initEP24AppleIntelBaseController",releaseDoorbell}, you get all other errors hmmm enable this patch and test {&kextG11FBT, f13b, r13b, arrsize(f13b), 1}, if you can disable all of your patches also test by disabling {&kextG11FBT, f19, r19, arrsize(f19), 1}, but yep the bug is in this zone Edited Sunday at 12:12 AM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Saturday at 11:53 PM Author Share Posted Saturday at 11:53 PM (edited) 11 minutes ago, jalavoui said: k checking log is perfect except for this because of this {"__ZN19AppleIntelPowerWell4initEP24AppleIntelBaseController",releaseDoorbell}, you get all other errors But without this I can't go on on the first PANIC_COND, it unblocks my initial stall and finally can have kp to resolve.. Edited Saturday at 11:54 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 12:04 AM Author Share Posted Sunday at 12:04 AM (edited) I noticed now that this r3 conf now give me a kp while before showed the square mouse and the default patch of nblue is showing now the square mouse and before the black screen 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, Edited Sunday at 12:05 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 12:11 AM Author Share Posted Sunday at 12:11 AM (edited) Don't pass the initial PANIC_COND and no kp log at next boot kern_gen11.cpp Edited Sunday at 12:14 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 12:16 AM Share Posted Sunday at 12:16 AM (edited) u miss read let me write again. nvm i'll reupload your file test it kern_gen11.cpp Edited Sunday at 12:18 AM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 12:22 AM Author Share Posted Sunday at 12:22 AM (edited) Patched hookcase, fix perms, reboot, and disable patch f19 r19... kp at boot but no logs at next kern_gen11.cpp Edited Sunday at 12:28 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 12:24 AM Share Posted Sunday at 12:24 AM (edited) i was about to send you a hookcase to test + gen11 here you go. if this doesnt work try this hack kern_gen11.cppHookCase.cpp anyway it's good we found the problem - now just need to make it work Edited Sunday at 12:32 AM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 12:34 AM Author Share Posted Sunday at 12:34 AM (edited) 16 minutes ago, jalavoui said: i was about to send you a hookcase to test + gen11 here you go kern_gen11.cpp 72.67 kB · 0 downloads HookCase.cpp 584.67 kB · 0 downloads You patched only "uint32_t AppleInteePortHAL::probePortMode()" and not "uint32_t AppleIntelPortHAL::probePortMode()" methods, it is correct? And the patch 19 in kern_gen11 is commented, so it reads from register 0x044470.. There's something wrong in these two files.. Ok then is good.. Edited Sunday at 12:42 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 12:39 AM Share Posted Sunday at 12:39 AM (edited) nvm uint32_t AppleInteePortHAL::probePortMode() it is for another kext (linked functions test) this is fine - it is disabled hookcase linux sources Edited Sunday at 12:48 AM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 12:49 AM Author Share Posted Sunday at 12:49 AM (edited) 27 minutes ago, jalavoui said: i was about to send you a hookcase to test + gen11 here you go. if this doesnt work try this hack kern_gen11.cpp 72.67 kB · 2 downloads HookCase.cpp 584.67 kB · 4 downloads anyway it's good we found the problem - now just need to make it work Try to guess? Stuck on panic_cond .. and no kp at next boot Edited Sunday at 12:52 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 12:54 AM Share Posted Sunday at 12:54 AM (edited) dam this is gonna take you more time to fix. hope you find a solution now that we know the problem do your best. idk try other things like the static const uint8_t r13b[] patch here's the linux logic start point linux seems to show you're on a display 13 Edited Sunday at 12:59 AM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 12:54 AM Author Share Posted Sunday at 12:54 AM 1 hour ago, ASUS Vivobook said: To avoid the collection of kp encountered I MUST enable these solving requests in order in the code you pass (that stalls to me), this is the minimal setup {"__ZN19AppleIntelPowerWell4initEP24AppleIntelBaseController",releaseDoorbell}, {"__ZN31AppleIntelRegisterAccessManager14ReadRegister32Em",raReadRegister32, this->oraReadRegister32}, {"__ZN19AppleIntelPowerWell19enableDisplayEngineEv",releaseDoorbell}, {"__ZN19AppleIntelPowerWell21hwSetPowerWellStatePGEbj",releaseDoorbell}, {"__ZN19AppleIntelPowerWell20disableDisplayEngineEv",releaseDoorbell}, {"__ZN19AppleIntelPowerWell22hwSetPowerWellStateAuxEbj",releaseDoorbell}, Then can finally boot without kp (but only mouse in video) and have finally logs (attached below) x.log.zip 1001.16 kB · 1 download Kernel-2024-11-10-000338.panic 6.78 kB · 1 download Kernel-2024-11-10-001043.panic 6.63 kB · 1 download Kernel-2024-11-10-001627.panic 6.63 kB · 1 download Kernel-2024-11-10-002134.panic 6.63 kB · 1 download Kernel-2024-11-10-002712.panic 7.68 kB · 1 download kern_gen11.cpp 73.17 kB · 2 downloads Without these my system won't boot... so... Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 01:43 PM Author Share Posted Sunday at 01:43 PM (edited) __text:00000000000E79B2 ; __int64 __fastcall IntelFBClientControl::vendor_doDeviceAttribute(__int64, int, __int64, __int64, __int64, __int64, __int64) __text:00000000000E79B2 __ZN20IntelFBClientControl24vendor_doDeviceAttributeEjPmmS0_S0_P25IOExternalMethodArguments proc near __text:00000000000E79B2 ; DATA XREF: __const:0000000000142128↓o __text:00000000000E79B2 ; __llvm_prf_data:00000000001894C8↓o __text:00000000000E79B2 __text:00000000000E79B2 var_40 = qword ptr -40h __text:00000000000E79B2 var_30 = dword ptr -30h __text:00000000000E79B2 var_28 = qword ptr -28h __text:00000000000E79B2 var_20 = qword ptr -20h __text:00000000000E79B2 var_18 = qword ptr -18h __text:00000000000E79B2 var_10 = qword ptr -10h __text:00000000000E79B2 var_8 = qword ptr -8 __text:00000000000E79B2 arg_0 = qword ptr 10h __text:00000000000E79B2 __text:00000000000E79B2 ; __unwind { __text:00000000000E79B2 push rbp __text:00000000000E79B3 mov rbp, rsp __text:00000000000E79B6 sub rsp, 40h __text:00000000000E79BA mov rax, rdi __text:00000000000E79BD mov r10, [rbp+arg_0] __text:00000000000E79C1 inc cs:qword_16DEE0 __text:00000000000E79C8 test r10, r10 __text:00000000000E79CB jz short loc_E7A2D __text:00000000000E79CD mov rdi, [rax+88h] __text:00000000000E79D4 mov [rbp+var_30], esi __text:00000000000E79D7 mov [rbp+var_28], rdx __text:00000000000E79DB mov [rbp+var_20], rcx __text:00000000000E79DF mov [rbp+var_18], r8 __text:00000000000E79E3 mov [rbp+var_10], r9 __text:00000000000E79E7 mov [rbp+var_8], r10 __text:00000000000E79EB mov rdi, [rdi+0E00h] __text:00000000000E79F2 test rdi, rdi __text:00000000000E79F5 jz short loc_E7A3E __text:00000000000E79F7 inc cs:qword_16DEF0 __text:00000000000E79FE inc cs:qword_16DEF8 __text:00000000000E7A05 mov r10, [rdi] __text:00000000000E7A08 mov [rsp+40h+var_40], 0 __text:00000000000E7A10 lea rsi, __ZN20IntelFBClientControl13actionWrapperEPvS0_S0_S0_ ; IntelFBClientControl::actionWrapper(void *,void *,void *,void *) __text:00000000000E7A17 lea rcx, [rbp+var_30] __text:00000000000E7A1B mov rdx, rax __text:00000000000E7A1E xor r8d, r8d __text:00000000000E7A21 xor r9d, r9d __text:00000000000E7A24 call qword ptr [r10+1A0h] __text:00000000000E7A2B jmp short loc_E7A51 __text:00000000000E7A2D ; --------------------------------------------------------------------------- __text:00000000000E7A2D __text:00000000000E7A2D loc_E7A2D: ; CODE XREF: IntelFBClientControl::vendor_doDeviceAttribute(uint,ulong *,ulong,ulong *,ulong *,IOExternalMethodArguments *)+19↑j __text:00000000000E7A2D inc cs:qword_16DEE8 __text:00000000000E7A34 mov [rsp+40h+var_40], 0 __text:00000000000E7A3C jmp short loc_E7A49 __text:00000000000E7A3E ; --------------------------------------------------------------------------- __text:00000000000E7A3E __text:00000000000E7A3E loc_E7A3E: ; CODE XREF: IntelFBClientControl::vendor_doDeviceAttribute(uint,ulong *,ulong,ulong *,ulong *,IOExternalMethodArguments *)+43↑j __text:00000000000E7A3E inc cs:qword_16DED8 __text:00000000000E7A45 mov [rsp+40h+var_40], r10 __text:00000000000E7A49 __text:00000000000E7A49 loc_E7A49: ; CODE XREF: IntelFBClientControl::vendor_doDeviceAttribute(uint,ulong *,ulong,ulong *,ulong *,IOExternalMethodArguments *)+8A↑j __text:00000000000E7A49 mov rdi, rax __text:00000000000E7A4C call __ZN20IntelFBClientControl11doAttributeEjPmmS0_S0_P25IOExternalMethodArguments This is the cause, I think test r10, r10 jz short loc_E7A2D Represented by 0x4D, 0x85, 0xD2, 0x74, 0x60 ******* Method "__ZN20IntelFBClientControl13actionWrapperEPvS0_S0_S0_" also call "ZN20IntelFBClientControl11doAttributeEjPmmS0_S0_P25IOExternalMethodArguments" inside its proc near; method whitch could be called also from the two statement above going forward in the code I put above.. " ******* lea rsi, __ZN20IntelFBClientControl13actionWrapperEPvS0_S0_S0_ is the only statement that only recall to "__ZN20IntelFBClientControl13actionWrapperEPvS0_S0_S0_" proc near ******* So, I tryed to remove the two statements above with ending zero filling 0x00 0x00 0x00 0x00 0x00 but the patch goes in panic!! //static const uint8_t f13c[]= {0x4D, 0x85, 0xD2, 0x74, 0x60, 0x48, 0x8B, 0xB8, 0x88, 0x00, 0x00, 0x00, 0x89, 0x75, 0xD0, 0x48, 0x89, 0x55, 0xD8, 0x48, 0x89, 0x4D, 0xE0, 0x4C, 0x89, 0x45, 0xE8, 0x4C, 0x89, 0x4D, 0xF0, 0x4C, 0x89, 0x55, 0xF8, 0x48, 0x8B, 0xBF, 0x00, 0x0E, 0x00, 0x00, 0x48, 0x85, 0xFF, 0x74, 0x47, 0x48, 0xFF, 0x05, 0xF2, 0x64, 0x08, 0x00, 0x48, 0xFF, 0x05, 0xF3, 0x64, 0x08, 0x00, 0x4C, 0x8B, 0x17, 0x48, 0xC7, 0x04, 0x24, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8D, 0x35, 0x65, 0xFF, 0xFF, 0xFF, 0x48, 0x8D, 0x4D, 0xD0, 0x48, 0x89, 0xC2, 0x45, 0x31, 0xC0, 0x45, 0x31, 0xC9, 0x41, 0xFF, 0x92, 0xA0, 0x01, 0x00, 0x00, 0xEB, 0x24}; //static const uint8_t r13c[]= {0x48, 0x8B, 0xB8, 0x88, 0x00, 0x00, 0x00, 0x89, 0x75, 0xD0, 0x48, 0x89, 0x55, 0xD8, 0x48, 0x89, 0x4D, 0xE0, 0x4C, 0x89, 0x45, 0xE8, 0x4C, 0x89, 0x4D, 0xF0, 0x4C, 0x89, 0x55, 0xF8, 0x48, 0x8B, 0xBF, 0x00, 0x0E, 0x00, 0x00, 0x48, 0x85, 0xFF, 0x74, 0x47, 0x48, 0xFF, 0x05, 0xF2, 0x64, 0x08, 0x00, 0x48, 0xFF, 0x05, 0xF3, 0x64, 0x08, 0x00, 0x4C, 0x8B, 0x17, 0x48, 0xC7, 0x04, 0x24, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8D, 0x35, 0x65, 0xFF, 0xFF, 0xFF, 0x48, 0x8D, 0x4D, 0xD0, 0x48, 0x89, 0xC2, 0x45, 0x31, 0xC0, 0x45, 0x31, 0xC9, 0x41, 0xFF, 0x92, 0xA0, 0x01, 0x00, 0x00, 0xEB, 0x24, 0x00, 0x00, 0x00, 0x00, 0x00}; it is not a good practice zeroing last part of a patch sequence? I thinked yes, but doesn't work.... Edited Sunday at 02:02 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 02:16 PM Author Share Posted Sunday at 02:16 PM (edited) Maybe I said some bulls***s because method __ZN20IntelFBClientControl24vendor_doDeviceAttributeEjPmmS0_S0_P25IOExternalMethodArguments proc near I found that is called externally by "com.apple.AppleGraphicsDeviceControl" so it's that the cause because it's recursive in my case.. this is a deep problem... Edited Sunday at 02:17 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 02:36 PM Author Share Posted Sunday at 02:36 PM (edited) Maybe my dGPU isn't disabled completely... maybe I must do an api to disable it instead use pic root disable-gpu true [EDIT] Done the .aml => nothing changed Edited Sunday at 03:07 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 03:22 PM Author Share Posted Sunday at 03:22 PM Maybe one port is the HDMI port.. i don't know.. Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 04:27 PM Author Share Posted Sunday at 04:27 PM (edited) https://dortania.github.io/OpenCore-Post-Install/gpu-patching/intel-patching/connector.html found this also about connectors.. and this https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md Edited Sunday at 04:32 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Mastachief Posted Sunday at 05:01 PM Share Posted Sunday at 05:01 PM The information in the dortiana github isn't based on icelake connectors which use 6 value sets instead of 3.The post I made in the main thread for the tglframebuffer was made as a way to consider using the same value set as the length of the alldata 'data' seeing its basically the same as icelake. Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 05:08 PM Share Posted Sunday at 05:08 PM (edited) no comments on your patch try (lol) the dgpu disable with opencore works very well what you asked are in the linux logs. problem is we an't trust apple code that's why we need always extra fixs. take this sample. there's no code for the DDI we use DDI(0) and DDI(1). maybe not best example but so you have a clue and because of this things ofc we need some hacks gonna try a little hack to help you download nblue+hookc srcs again disable this call in nblue bool Gen11::AppleIntelBaseControllerstart(void *that,void *param_1) apply this patch in the tgl debug frameb find 0xe8, 0x67, 0x63, 0x35, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00 replace 0xe8, 0x67, 0x63, 0x35, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x48, 0xe9, 0xd2, 0x00, 0x00, 0x00 build nblue+hookcase binarys another aproach is use wg trick. to disabled agdc calls. but this is a bit harder todo on tgl cause tgl as extra calls to agdc todo so better read from main thread. maybe it gives you new ideas Edited Sunday at 05:41 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 06:09 PM Author Share Posted Sunday at 06:09 PM (edited) find 0xe8, 0x67, 0x63, 0x35, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00 replace 0xe8, 0x67, 0x63, 0x35, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x48, 0xe9, 0xd2, 0x00, 0x00, 0x00 Found "E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00" in tglfb with IDA PRO hangs at boot Edited Sunday at 08:48 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 06:22 PM Share Posted Sunday at 06:22 PM (edited) if you try the agdc bypass you gonna need at least this patch. so find be 04 00 00 00 48 89 da 31 c9 e8 8c ac 04 00 replace be 04 00 00 00 48 89 da 31 c9 90 90 90 90 90 patch __ZN20IntelFBClientControl11doAttributeEjPmmS0_S0_P25IOExternalMethodArguments with code from icl it's already there just copy to tgl code anohter idea from log this can be patched might fix all so try this patch only forget others find e9 1a 01 00 00 8d 43 fe 83 f8 02 0f 83 f8 00 00 00 replace e9 1a 01 00 00 8d 43 fe 83 f8 02 48 e9 08 01 00 00 Edited Sunday at 06:55 PM by jalavoui Link to comment Share on other sites More sharing options...
benmacfreak Posted Sunday at 07:43 PM Share Posted Sunday at 07:43 PM 1 hour ago, jalavoui said: if you try the agdc bypass you gonna need at least this patch. so find be 04 00 00 00 48 89 da 31 c9 e8 8c ac 04 00 replace be 04 00 00 00 48 89 da 31 c9 90 90 90 90 90 patch __ZN20IntelFBClientControl11doAttributeEjPmmS0_S0_P25IOExternalMethodArguments with code from icl it's already there just copy to tgl code anohter idea from log this can be patched might fix all so try this patch only forget others find e9 1a 01 00 00 8d 43 fe 83 f8 02 0f 83 f8 00 00 00 replace e9 1a 01 00 00 8d 43 fe 83 f8 02 48 e9 08 01 00 00 i didn't see the nblue src zip in the other thread jala idk why or what page in the thread it's on. I only saw the old one i linked. Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 08:04 PM Author Share Posted Sunday at 08:04 PM Link to comment Share on other sites More sharing options...
Recommended Posts