Jump to content

[Acer PT14-51 Laptop] HowTo


Stezza88
 Share

482 posts in this topic

Recommended Posts

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 by ASUS Vivobook
Link to comment
Share on other sites

k checking

 

log is perfect except for this

 

image.png.190bc327c85d2c14146b5835de042e6a.png

 

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 by jalavoui
  • Like 1
Link to comment
Share on other sites

11 minutes ago, jalavoui said:

k checking

 

log is perfect except for this

 

image.png.190bc327c85d2c14146b5835de042e6a.png

 

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 by ASUS Vivobook
Link to comment
Share on other sites

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 by ASUS Vivobook
Link to comment
Share on other sites

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 by ASUS Vivobook
Link to comment
Share on other sites

 

 

nvm uint32_t AppleInteePortHAL::probePortMode()

it is for another kext (linked functions test)

 

this is fine - it is disabled

image.png.f52b0df5e381c3e2054d52e94dd83df7.png

 

hookcase

image.png.26154ac41938f17fa9b7235506d4355f.png

 

linux sources

image.png.bee070547752afdc9cfe484d8379ea33.png

Edited by jalavoui
  • Like 1
Link to comment
Share on other sites

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

image.png.9fd3528eac4b627889b91779ca9b774d.png

 

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 by ASUS Vivobook
Link to comment
Share on other sites

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

image.png.e0f018a9cf8f6bfeb91fbe83636ac765.png

 

linux seems to show you're on a display 13

Edited by jalavoui
Link to comment
Share on other sites

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

__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 by ASUS Vivobook
Link to comment
Share on other sites

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 by ASUS Vivobook
Link to comment
Share on other sites

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 by ASUS Vivobook
Link to comment
Share on other sites

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

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

image.png.c689cabd0e37e25816db8917aa8f364a.png

 

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

image.thumb.png.a9eb7d27382ca4b2c6283850f9a638dd.png

todo so better read from main thread. maybe it gives you new ideas 

Edited by jalavoui
  • Like 1
Link to comment
Share on other sites

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 by ASUS Vivobook
Link to comment
Share on other sites

if you try the agdc bypass you gonna need at least this patch.

 

image.png.f873cee011648367a6cc9ede1c1bf60d.png

 

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

image.thumb.png.1d2844e8619b1d1dbd93e56d389c7172.png

 

anohter idea

from log this can be patched

image.png.eef71dfd32a5585c4de7bd6d31cd532e.png

 

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 by jalavoui
Link to comment
Share on other sites

1 hour ago, jalavoui said:

if you try the agdc bypass you gonna need at least this patch.

 

image.png.f873cee011648367a6cc9ede1c1bf60d.png

 

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

image.thumb.png.1d2844e8619b1d1dbd93e56d389c7172.png

 

anohter idea

from log this can be patched

image.png.eef71dfd32a5585c4de7bd6d31cd532e.png

 

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

 Share

×
×
  • Create New...