[Acer PT14-51 Laptop] HowTo

[jalavoui]

u miss read let me write again. nvm i'll reupload your file

 

test it

 

kern_gen11.cpp

Edited November 10, 2024 by jalavoui

[Stezza88]

Patched hookcase, fix perms, reboot, and disable patch f19 r19... kp at boot but no logs at next

kern_gen11.cpp

Edited November 10, 2024 by ASUS Vivobook

[jalavoui]

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 November 10, 2024 by jalavoui

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[jalavoui]

 

 

nvm uint32_t AppleInteePortHAL::probePortMode()

it is for another kext (linked functions test)

 

this is fine - it is disabled

 

hookcase

 

linux sources

Edited November 10, 2024 by jalavoui

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[jalavoui]

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 November 10, 2024 by jalavoui

[Stezza88]

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...

[Stezza88]

__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 November 10, 2024 by ASUS Vivobook

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[Stezza88]

Maybe one port is the HDMI port.. i don't know..

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[Mastachief]

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.

[jalavoui]

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 November 10, 2024 by jalavoui

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[jalavoui]

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 November 10, 2024 by jalavoui

[benmacfreak]

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.

[Stezza88]

 

[benmacfreak]

1 minute ago, ASUS Vivobook said:

 

thanks

[Stezza88]

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 November 10, 2024 by ASUS Vivobook

[jalavoui]

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 November 10, 2024 by jalavoui

[Stezza88]

(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 November 10, 2024 by ASUS Vivobook

[jalavoui]

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 November 10, 2024 by jalavoui

[Stezza88]

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 November 10, 2024 by ASUS Vivobook