benmacfreak Posted Sunday at 08:06 PM Share Posted Sunday at 08:06 PM 1 minute ago, ASUS Vivobook said: thanks Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 09:09 PM Author Share Posted Sunday at 09:09 PM (edited) The first static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00}; static const uint8_t r6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x48, 0xe9, 0xd2, 0x00, 0x00, 0x00}; (modified because i won't found your) stalls on boot The second static const uint8_t f6b[]= {0xbe, 0x04, 0x00, 0x00, 0x00, 0x48, 0x89, 0xda, 0x31, 0xc9, 0xe8, 0x8c, 0xac, 0x04, 0x00}; static const uint8_t r6b[]= {0xbe, 0x04, 0x00, 0x00, 0x00, 0x48, 0x89, 0xda, 0x31, 0xc9, 0x90, 0x90, 0x90, 0x90, 0x90}; boot but on black screen with conn0 as 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, No log but kp Kernel-2024-11-10-221216.panic But adding {"__ZN24AppleIntelBaseController15hwWaitForVBlankEP21AppleIntelFramebufferj",releaseDoorbell}, boot on black screen with square mouse and got logs x.log Edited Sunday at 09:23 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 09:23 PM Share Posted Sunday at 09:23 PM (edited) forget the agdc callback and agdc patch for now this is the place of the agdc callback patch. maybe i forgot to zero some bytes focus on your last panic. it's probably a div by zero so the code is here change 75 2e to eb 2e it's a simple jmp hope this won't turn in a bunch of new errors. we aren't fixing the origin of the problem Edited Sunday at 09:39 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 09:25 PM Author Share Posted Sunday at 09:25 PM (edited) (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 34 ][allocatePorts ] portCount = 3 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 77 ][allocatePorts ] ret = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 116 ][resetSoftwareState ] DDI = 0 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 108 ][init ] PortIndex = 0, DDI = 0 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPortHAL.cpp : 452 ][init ] ret = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DIAGS ][AppleIntelDiags.cpp : 2066 ][init ] DDI = 0 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DIAGS ][AppleIntelDiags.cpp : 2078 ][init ] ret = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 116 ][resetSoftwareState ] DDI = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 108 ][init ] PortIndex = 1, DDI = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPortHAL.cpp : 452 ][init ] ret = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DIAGS ][AppleIntelDiags.cpp : 2066 ][init ] DDI = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DIAGS ][AppleIntelDiags.cpp : 2078 ][init ] ret = 1 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 116 ][resetSoftwareState ] DDI = 2 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 108 ][init ] PortIndex = 2, DDI = 2 ... (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][PORT ][AppleIntelPort.cpp : 237 ][getBuiltInPort ] Built-in PortIndex = 0, DDI = 0 In the post above the new log Edited Sunday at 09:38 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 09:40 PM Share Posted Sunday at 09:40 PM (edited) don't you wanna change this title to something with Raptor Lake ? it's your card family hmm maybe i can call my thread jalavoui great driver Edited Sunday at 09:41 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 09:41 PM Author Share Posted Sunday at 09:41 PM (edited) 8 minutes ago, jalavoui said: don't you wanna change this title to something with Raptor Lake ? it's your card family Can't change! Already tryed.. this forum don't permit it... I ve reached to put only the tag [EDIT] in something like "how to burn a Raptor Lake".. when i turn to Windows now my fan goes deep Edited Sunday at 09:49 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 10:04 PM Share Posted Sunday at 10:04 PM do you have a full log? 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 10:12 PM Author Share Posted Sunday at 10:12 PM (edited) 10 minutes ago, jalavoui said: do you have a full log? up x.log Edited Sunday at 10:15 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 10:31 PM Share Posted Sunday at 10:31 PM (edited) looks like your card is working. is this so ? only diff from mine is synctovbl - yours is on top synctovbl=1 Edited Sunday at 10:33 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 10:32 PM Author Share Posted Sunday at 10:32 PM Just now, jalavoui said: looks like your card is working. is this so ? No. Black screen and square mouse Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 10:45 PM Share Posted Sunday at 10:45 PM (edited) found a cause (maybe 2 much hacks) check is here. but the value read is so wrong patching this might be a bad idea this is link size check patch. well you can try let me check bytes to change k here you go changed bytes 0f 82... to 48 e9 use a bigger byte chain so they dont exist somewherelse the pixel value is wrong. idk why this happened. this patch will pass a wrong value... this is the field with the wrong value Edited Sunday at 11:30 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 10:48 PM Author Share Posted Sunday at 10:48 PM (edited) 30 minutes ago, jalavoui said: found a cause (maybe 2 much hacks) patches acrive maybe I can disable something {&kextG11FBT, f2, r2, arrsize(f2), 1}, {&kextG11FBT, f3, r3, arrsize(f3), 1}, {&kextG11FBT, f6b, r6b, arrsize(f6b), 1}, //jalapatch {&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, f19, r19, arrsize(f19), 1}, {&kextG11FBT, f20, r20, arrsize(f20), 1}, Edited Sunday at 11:16 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 11:06 PM Share Posted Sunday at 11:06 PM (edited) don't you miss previous patches? the base patches are fine ups i patched the wrong part of code. that previous patch is for link size check this is the data size check so change to a jump Edited Sunday at 11:16 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 11:07 PM Author Share Posted Sunday at 11:07 PM (edited) 4 minutes ago, jalavoui said: don't you miss previous patches? the base patches are fine CRT patch stucks on boot static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00}; static const uint8_t r6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x48, 0xe9, 0xd2, 0x00, 0x00, 0x00}; Edited Sunday at 11:10 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 11:19 PM Share Posted Sunday at 11:19 PM (edited) static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00}; this is not found let me chek this is what i posted earlier. it exists lol i just read you tryed to hack my bytes don't do that bad things happen so use this patch +data size check that i just posted i wonder how you get that log without this patch. but dam i was rigth all this problems is cause of bad agdc timmings Edited Sunday at 11:28 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 11:27 PM Author Share Posted Sunday at 11:27 PM (edited) LinkM value too big: 53c4cf000 x.log 8 minutes ago, jalavoui said: static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00}; this is not found let me chek this is what i posted earlier. it exists lol i just read you tryed to hack my bytes don't do that bad things happen so use this patch +data size check that i just posted I don't found yours! Are we using the same tgl framebuffer? Have you updated it? Edited Sunday at 11:28 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 11:29 PM Share Posted Sunday at 11:29 PM (edited) yes the debug version. the link patch is already posted. funny it also fails my 1st tought was to patch the pixel field but idk if it gonna work Edited Sunday at 11:38 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 11:37 PM Author Share Posted Sunday at 11:37 PM (edited) 22 minutes ago, jalavoui said: static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00}; this is not found let me chek this is what i posted earlier. it exists lol i just read you tryed to hack my bytes don't do that bad things happen so use this patch +data size check that i just posted i wonder how you get that log without this patch. but dam i was rigth all this problems is cause of bad agdc timmings I downloaded the last sle internal, opened le tgl fb in IDA PRO and I don't found your byte sequence!!!! I found mine! I find "E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00" not yours! yours not exist Edited Sunday at 11:42 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 11:40 PM Share Posted Sunday at 11:40 PM (edited) hmm sec. you're right about E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00 gonna reload the bin in ghidra strange thing k so ghidra as this bytes e8 67 63 35 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00 and ida pro E8 37 A9 30 00 41 83 BC 24 54 01 00 00 00 0F 88 D2 00 00 00 can't find any of this bytes in binary with hexedit... gonna check with bninja got other bytes ... well try with the bytes you found - guess it works change last part 0x0f 0x88 to 0x48 0xe9 if you don't a kp with lilu message then the patch is found Edited Sunday at 11:58 PM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Sunday at 11:56 PM Author Share Posted Sunday at 11:56 PM (edited) 15 minutes ago, jalavoui said: hmm sec. you're right about E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00 gonna reload the bin in ghidra strange thing k so ghidra as this bytes e8 67 63 35 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00 and ida pro E8 37 A9 30 00 41 83 BC 24 54 01 00 00 00 0F 88 D2 00 00 00 can't find any of this bytes in binary with hexedit... gonna check with bninja Very strange : both the patch stall to me... so... Edited Sunday at 11:56 PM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 11:59 PM Share Posted Sunday at 11:59 PM (edited) yeah sometimes i get that bug. i think its a decompiler issue. when this happens i try other bytes. sec k this are bytes near the jump. check find 0f 88 d2 00 00 00 48 ff 05 71 a5 0e 00 be a0 00 00 00 replace 48 e9 d2 00 00 00 48 ff 05 71 a5 0e 00 be a0 00 00 00 this bytes works. they exist in the binary. hexedit dont lie dam dissasemblers!! data size bytes checked find 0f 86 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 9f 78 0e 00 bf 08 00 00 00 rep 48 e9 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 9f 78 0e 00 bf 08 00 00 00 link pass bytes checked find 0f 82 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 80 77 0e 00 rep 48 e9 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 80 77 0e 00 i dont like this hack but give it a try Edited Monday at 12:19 AM by jalavoui Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 12:16 AM Author Share Posted Monday at 12:16 AM (edited) Bad signals... black screen with square mouse.. 2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelController.cpp : 7724 ][SetupDPSSTTimings ] pixelClock=-446376717216, linkSymbolClock=810000000, colorDepth=24, noLanes=4 2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelController.cpp : 7777 ][SetupDPSSTTimings ] DataM value: 570f698 2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelController.cpp : 7784 ][SetupDPSSTTimings ] LinkM value too big: 53c335000 2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelController.cpp : 7785 ][SetupDPSSTTimings ] return -536870212 ... (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelFB.cpp : 4131 ][setAttributeForConne] Bad Scale value = 65536 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelFB.cpp : 4149 ][setAttributeForConne] Bad Scale value = 65536 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY ][AppleIntelFB.cpp : 4166 ][setAttributeForConne] Bad Scale value = 65536 x.log Edited Monday at 12:23 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 12:19 AM Share Posted Monday at 12:19 AM (edited) link check failed? wtf let me see the patch is ok. did u use the link patch? right the pixel field as wrong value so the link patch not enough let me try a field patch so this means i'll hack the field to get this value... k here they are find 84 c0 0f 84 dd 00 00 00 48 ff 05 80 7d 0e 00 49 8b 85 18 01 00 00 rep 84 c0 49 c7 85 18 01 00 00 00 e9 05 11 90 90 49 8b 85 18 01 00 00 the rep value is the previous pixel value 0x1105E900 = 285 600 000 this is very bad practice and i dont know the guy who did this ! Edited Monday at 12:33 AM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 12:27 AM Author Share Posted Monday at 12:27 AM no.. do it now Link to comment Share on other sites More sharing options...
Stezza88 Posted Monday at 12:33 AM Author Share Posted Monday at 12:33 AM (edited) Better log, but same result... pixelClock=-438333250464 Bad Scale value = 65536 Bad Scale value = 65536 Bad Scale value = 65536 x.log Edited Monday at 12:36 AM by ASUS Vivobook Link to comment Share on other sites More sharing options...
Recommended Posts