jalavoui Posted Monday at 05:14 PM Share Posted Monday at 05:14 PM (edited) try this static const uint8_t f13[]= {0xff, 0x91, 0x90, 0x01, 0x00, 0x00, 0x83, 0xf8, 0x02, 0x0f, 0x84, 0xec, 0x00, 0x00, 0x00}; static const uint8_t r13[]= {0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90}; enable this patch static const uint8_t f16[]= {0x48, 0x89, 0x05, 0xfc, 0x39, 0x12, 0x00, 0x48, 0x8b, 0x83, 0x48, 0x05, 0x00, 0x00, 0xf6, 0x40, 0x14, 0x08, 0x75, 0x0d}; static const uint8_t r16[]= {0x48, 0x89, 0x05, 0xfc, 0x39, 0x12, 0x00, 0x48, 0x8b, 0x83, 0x48, 0x05, 0x00, 0x00, 0xf6, 0x40, 0x14, 0x08, 0x90, 0x90}; try not to disable functions - bad idea Edited Monday at 05:15 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 05:25 PM Author Share Posted Monday at 05:25 PM (edited) We forget to change also this if we disabled patch f19 r19 unsigned long Gen11::getHPDState(void *that) { unsigned int uVar3 =callback->wrapReadRegister32(that, 0x044470); Now got better logs with only these patches LookupPatchPlus const patches[] = {// tgl debug kext {&kextG11FBT, f2, r2, arrsize(f2), 1}, {&kextG11FBT, f7, r7, arrsize(f7), 1}, {&kextG11FBT, f10, r10, arrsize(f10), 1}, {&kextG11FBT, f13, r13, arrsize(f13), 1}, {&kextG11FBT, f13b, r13b, arrsize(f13b), 1}, {&kextG11FBT, f15, r15, arrsize(f15), 1}, {&kextG11FBT, f20, r20, arrsize(f20), 1}, }; I must still read your last post! ..but better logs, calculation are working without patches now!! Last log start at 18:16:39.094974+0100 x.log.zip Edited Monday at 05:44 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 05:49 PM Author Share Posted Monday at 05:49 PM Also this now works! (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelController.cpp : 8786 ][SetupTimings ] timing ha=2560, va=1600 Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 05:54 PM Author Share Posted Monday at 05:54 PM (edited) 42 minutes ago, jalavoui said: try this static const uint8_t f13[]= {0xff, 0x91, 0x90, 0x01, 0x00, 0x00, 0x83, 0xf8, 0x02, 0x0f, 0x84, 0xec, 0x00, 0x00, 0x00}; static const uint8_t r13[]= {0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90}; enable this patch static const uint8_t f16[]= {0x48, 0x89, 0x05, 0xfc, 0x39, 0x12, 0x00, 0x48, 0x8b, 0x83, 0x48, 0x05, 0x00, 0x00, 0xf6, 0x40, 0x14, 0x08, 0x75, 0x0d}; static const uint8_t r16[]= {0x48, 0x89, 0x05, 0xfc, 0x39, 0x12, 0x00, 0x48, 0x8b, 0x83, 0x48, 0x05, 0x00, 0x00, 0xf6, 0x40, 0x14, 0x08, 0x90, 0x90}; try not to disable functions - bad idea Must try this the same? Edited Monday at 05:56 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 05:58 PM Share Posted Monday at 05:58 PM (edited) good. fix hookcase also. or use 13b patch f13 patch is to poweroff aux. and disable probeportmode f16 disable builtin check and makes agdc returns 0x2. test it the pixel clock still wrong. wrapConnectionProbe() helps? Edited Monday at 06:06 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 06:11 PM Author Share Posted Monday at 06:11 PM (edited) . Edited Monday at 06:38 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 06:21 PM Author Share Posted Monday at 06:21 PM (edited) With new f13 patch, instead patch f16 must disable because it stalls on boot to me, log unchanged from previous (I think) wrapConnectionProbe is in use but I don't see changement (I think), hookcase already fixed to 0x044470 Patch in use : ookupPatchPlus const patches[] = {// tgl debug kext {&kextG11FBT, f2, r2, arrsize(f2), 1}, {&kextG11FBT, f7, r7, arrsize(f7), 1}, {&kextG11FBT, f10, r10, arrsize(f10), 1}, {&kextG11FBT, f13, r13, arrsize(f13), 1}, {&kextG11FBT, f15, r15, arrsize(f15), 1}, {&kextG11FBT, f20, r20, arrsize(f20), 1}, }; x.log Edited Monday at 06:34 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 06:27 PM Author Share Posted Monday at 06:27 PM (edited) I disabled f3 connectors patch also.. I don't know if changes something but.. but I see square mouse without it pixelclock values come from agdc in my opinion, in the post above the log with new f13 patch, f16 stall on boot Edited Monday at 06:39 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 06:38 PM Share Posted Monday at 06:38 PM (edited) that's what i tough you only needed to change port connection. disabling f3 will use default connectors so you're now using the 1st line if you wanna change something copy it to r3 if this fixed pipe0 then maybe u can enabled the powerwell,etc functions try to disable the f10 patch so the display can power cycle. might give new pixelclocks and check this patches https://github.com/joevt/WhateverGreen/commits/master/ the CheckTimingWithRange() will load in DYLDPatches with some mods. i write about it on main thread Edited Monday at 06:58 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 07:25 PM Author Share Posted Monday at 07:25 PM (edited) New patch 3 doesn't affected the result to me. Disabling patch 10 I collected a new series of kp and full black screen, I think is no good to my case disabling it. This patch? // 14.7, 15.0 // Patch created by kokozaurs https://github.com/oskarstr static const uint8_t CheckTimingWithRange_Find_14_0[] = { 0x8B, 0x42, 0x20, // mov eax, dword [rdx+0x20] 0x41, 0xBF, 0x01, 0x00, 0x00, 0x00, // mov r15d, 0x1 0xA8, 0x01, // test al, 0x1 0x0F, 0x85 // jne <somewhere> }; static const uint8_t CheckTimingWithRange_Repl_14_0[] = { 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, // nop (6x) 0x41, 0xBF, 0x00, 0x00, 0x00, 0x00, // mov r15d, 0x0 0xE9 // jmp <somewhere> }; This should be wrong in your opinion? (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelFB.cpp : 1853 ][initTimingRange ] (minClock=20000000, maxClock=720000000) Edited Monday at 07:44 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 07:54 PM Share Posted Monday at 07:54 PM (edited) ignore for now minClock. leave for the acelerator phase let me try remenber patch mod load dyld cache with hoper and open core display bytes are here (depend on os x version) because the bytes can match agains other libs copy a big hex string and change the jne to jump in hoper and copy the bytes to DYLDPatches.cpp some patch samples are already there (remove the return; at top to use dyldpatches) idk what else can help you gl Edited Monday at 08:09 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 08:13 PM Author Share Posted Monday at 08:13 PM How can "load dyld cache" ? Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 08:33 PM Share Posted Monday at 08:33 PM (edited) file-read dyld in hopper use copy hex string of bytes to get bytes from hopper replace the f4 when you create the new patch + comment this line. sample for my ventura version - in hopper choose modify - assemble instruction find BB 01 00 00 00 A8 01 0F 85 6F 07 00 00 49 89 D7 49 89 F6 A8 04 74 0B 41 F6 46 3C 0C 0F 84 4E 07 00 00 rep BB 01 00 00 00 A8 01 E9 70 07 00 00 90 49 89 D7 49 89 F6 A8 04 74 0B 41 F6 46 3C 0C 0F 84 4E 07 00 00 Edited Monday at 08:45 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 08:38 PM Author Share Posted Monday at 08:38 PM (edited) So.. I think that the patch by joevt is good for my system... Edited Monday at 08:41 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 08:41 PM Share Posted Monday at 08:41 PM (edited) yes you are full of bugs. i tested to force orignal conn zero - the reading of pixel fails,etc,etc good you found the solution Edited Monday at 08:44 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 08:52 PM Author Share Posted Monday at 08:52 PM Seems nothing has changed... x.log Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 09:16 PM Share Posted Monday at 09:16 PM upload kern_gen11.cpp Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 09:27 PM Author Share Posted Monday at 09:27 PM (edited) HookCase.cpp kern_gen11.cpp kern_gen11.hpp Edited Monday at 09:29 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 09:42 PM Share Posted Monday at 09:42 PM (edited) the pacthes will fail with this (wrong size) k test it. need to find out where it hangs or crashes disabling functions is wasting time kern_gen11.cpp Edited Monday at 09:54 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 09:50 PM Author Share Posted Monday at 09:50 PM (edited) Changed.. always black screen with square mouse Don't know where we can go.. the log is good now... Edited Monday at 09:53 PM by Stezza88 Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 10:01 PM Share Posted Monday at 10:01 PM (edited) you tested the file i just send? got logs? disable wrapConnectionProbe() if you get hang at boot Edited Monday at 10:06 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 10:07 PM Author Share Posted Monday at 10:07 PM To me it hangs on boots because it cannot resolve the dependencie to powerwellinit that some of the requests you put into the solving array calls.. it not crash but the panic cone stuck and no kp is printed. Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 10:12 PM Author Share Posted Monday at 10:12 PM I've tryed to pass from panic cond to syslog cond but it hangs the same.. Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 10:23 PM Author Share Posted Monday at 10:23 PM (edited) Disabled wrapConnectionProbe, hang and no kp log.. if I put power well init unblock but then chain of kp.. want to guess? Edited Monday at 10:23 PM by Stezza88 Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 10:23 PM Share Posted Monday at 10:23 PM (edited) 28 minutes ago, Stezza88 said: To me it hangs on boots because it cannot resolve the dependencie to powerwellinit that some of the requests you put into the solving array calls.. it not crash but the panic cone stuck and no kp is printed. that is impossible patches dont depended on functions. it is hanging on the conn zero enable wrapConnectionProbe() and use this conn static const uint8_t r3[]= { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x01, 0x02, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x01, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; do not disabled any function ! understand that doing that only makes the driver load with bugs you need to find a conn combo that allows the driver to load that is how current tgl driver works ofc we got other bugs to solve but the process is the same Edited Monday at 10:36 PM by jalavoui Link to comment Share on other sites More sharing options...
Recommended Posts