Jump to content
500 posts in this topic

Recommended Posts

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 by jalavoui

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 by ASUS Vivobook
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 by ASUS Vivobook

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 by jalavoui

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 by ASUS Vivobook

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 by ASUS Vivobook

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

 

image.thumb.png.473ae63cad22211baf18df3f72ba797b.png

 

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 by jalavoui

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 by ASUS Vivobook

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)

image.thumb.png.14949b2845ec616e54f7ed711a1d0003.png

 

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 by jalavoui

file-read dyld in hopper

image.png.23cb0e9bf64fb91032c215d41296fbab.png

 

use copy hex string of bytes to get bytes from hopper

 

replace the f4 when you create the new patch

 

image.png.c10ee161299c242ae7e51c46a39407fe.png

 

+ comment this line.

image.png.690e7a9b8271747928ff26d3a21a1f22.png

 

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

 

image.png.246ca171e28b271e3e2e144ae05566b5.png

 

Edited by jalavoui

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.

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 by jalavoui
×
×
  • Create New...