[Acer PT14-51 Laptop] HowTo

[jalavoui]

that code is disabled in nblue latest

 

 

this is to load signed tgl - only possible from /S/L/E

 

but you can test on /L/E just install tgl graph from /sle_Internal/le and change the path in nblue

 

to test in /S/L/E only by breaking os x seal. if u never did it you will probably break os x (read other thread)

Edited November 5, 2024 by jalavoui

[Stezza88]

Got these kps when I copy files into L E with nb in boot ... I'm gonna reusing weg to do it... with weg no problems...

 

nblue : genx Failed to resolve symbols

nblue : genx Failed to route symbols

Kernel-2024-11-05-012957.panic

Kernel-2024-11-05-013711.panic

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

you can't copy kexts from /sle_Internal/sle  to /L/E cause they are signed. copying bundles might be ok

 

in /L/E use kexts from /sle_Internal/le

 

that's why u got a kp

 

but yeah wg is also ok for test new patches

 

make sure you have kextacache of /L/E working

Edited November 5, 2024 by jalavoui

[Stezza88]

It boots always on gen7icl and It's empty the IOPrimaryMatch inside

NootedBlue     nblue: @ kextG11HW Failed to apply patches!
NootedBlue     nblue: @ Loaded AppleIntelICLGraphics!

but I've choosen TGL... can't understand why

 

 

Tryed to clean nvram too and nothing changes..

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

that's strange if icl id is empty (try use fake id just in case put 0x12348086 instead of empty to disable)

 

i think nblue will hang on icl framebuffer b4 loading icl graph kext but...

 

nblue patches failed as the log says. disable what you dont need. check here (enable panic_Cond maybe)

if 1 patch fails you get that msg no matter if others are correct.

maybe replace f2 with your patch and disable others?

 

 

LookupPatchPlus const patchesc[] = { are for mac os catalina - ignore them

Edited November 5, 2024 by jalavoui

[Stezza88]

19 minutes ago, jalavoui said:

that's strange if icl id is empty (try use fake id just in case put 0x12348086 instead of empty to disable)

 

i think nblue will hang on icl framebuffer b4 loading icl graph kext but...

 

nblue patches failed as the log says. disable what you dont need. check here (enable panic_Cond maybe)

if 1 patch fails you get that msg no matter if others are correct.

maybe replace f2 with your patch and disable others?

 

 

LookupPatchPlus const patchesc[] = { are for mac os catalina - ignore them

 

I put 0x12348086 on Gen7icl and my id in gen7tgl and It comes loaded Always gen7icl ... It's indestructible

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

can you upload the nblue src that you are using. maybe u modify something wrong.

 

or you can try to delete Gen7ICL from the info.plist if that helps

 

oh w8 did you modify the kexts info.plist inside /L/E  - check that first

Edited November 5, 2024 by jalavoui

[Stezza88]

kern_gen11.cpp kern_nblue.cp

 

Nblue in use

NootedBlue.kext.zip

 

L/E plist of AppleIntelTGLGraphics

Info.plist

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

hmmm.

 

does kextload -v 6 gives errors for tgl graph loading?

 

nvm i found the bug

 

change this 

 

to

nblue default

 

 

 

if you need to use icl id just remove //   and comment 0x9a49 

 

icl id is 0x8a5c

tgl id is 0x9a49

 

but carefull cause this changes device-id and also ig-platformid

 

 

this is funny u tell os x that your card id is 0x8a5c and ig-platform is 0x9a4a

i think os x went crazy

 

Edited November 5, 2024 by jalavoui

[Stezza88]

5 minutes ago, jalavoui said:

hmmm.

 

does kextload -v 6 gives errors for tgl graph loading?

 

No but i delete and reload as a try now..

Got a kp when delete It...

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

kp are your friend dont complain if you get a kp log.

 

fix the wrong ids in nblue. let me explain better

 

use this if testing icl kexts

 

use this if testing tgl kexts

 

or idk you can comment all the code (+2 lines for properties inject) and do this with opencore properties

 

the icl indestructible was funny !

Edited November 5, 2024 by jalavoui

[Stezza88]

9 hours ago, jalavoui said:

hmmm.

 

does kextload -v 6 gives errors for tgl graph loading?

 

nvm i found the bug

 

change this 

 

to

nblue default

 

 

 

if you need to use icl id just remove //   and comment 0x9a49 

 

icl id is 0x8a5c

tgl id is 0x9a49

 

but carefull cause this changes device-id and also ig-platformid

 

 

this is funny u tell os x that your card id is 0x8a5c and ig-platform is 0x9a4a

i think os x went crazy

 

 

Nothing fuc*** changes!

Always load Gen7icl..

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

oh yes i forgot if you use tgl from sle_Internal/lep that is production version. then u need to use the patches with "p" in nblue and disable the others.

 

but you problem with icl graph is strange. only possible with wrong device-id or ig-platform

[Stezza88]

bool Gen11::processKext (..) {
  SYSLOG("SYSLOG", "index %lu", index);
  SYSLOG("SYSLOG", "kextG11FB.loadIndex : %lu", kextG11FB.loadIndex);
  SYSLOG("SYSLOG", "kextG11HW.loadIndex : %lu", kextG11HW.loadIndex);
  SYSLOG("SYSLOG", "kextG11HWT.loadIndex %lu", kextG11HWT.loadIndex);
  SYSLOG("SYSLOG", "kextG11FBT.loadIndex : %lu", kextG11FBT.loadIndex);
  ...
}

Wanna check this piece of code..

 

[EDIT] Got this : ( now it hits good! TGL seems loaded ... were my logs that weren't updated, sorry for the inconventient )

However, method Gen11::processKext came called multiple times... it is correct?

...
NootedBlue    SYSLOG: @ index 1
NootedBlue    SYSLOG: @ kextG11FB.loadIndex : 4
NootedBlue    SYSLOG: @ kextG11HW.loadIndex : 5
NootedBlue    SYSLOG: @ kextG11HWT.loadIndex 7
NootedBlue    SYSLOG: @ kextG11FBT.loadIndex : 6
...
NootedBlue    SYSLOG: @ index 8
NootedBlue    SYSLOG: @ kextG11FB.loadIndex : 4
NootedBlue    SYSLOG: @ kextG11HW.loadIndex : 5
NootedBlue    SYSLOG: @ kextG11HWT.loadIndex 7
NootedBlue    SYSLOG: @ kextG11FBT.loadIndex : 6
...
NootedBlue    SYSLOG: @ index 9
NootedBlue    SYSLOG: @ kextG11FB.loadIndex : 4
NootedBlue    SYSLOG: @ kextG11HW.loadIndex : 5
NootedBlue    SYSLOG: @ kextG11HWT.loadIndex 7
NootedBlue    SYSLOG: @ kextG11FBT.loadIndex : 6
...
NootedBlue    SYSLOG: @ index 10
NootedBlue    SYSLOG: @ kextG11FB.loadIndex : 4
NootedBlue    SYSLOG: @ kextG11HW.loadIndex : 5
NootedBlue    SYSLOG: @ kextG11HWT.loadIndex 7
NootedBlue    SYSLOG: @ kextG11FBT.loadIndex : 6
...
NootedBlue    SYSLOG: @ index 7
NootedBlue    SYSLOG: @ kextG11FB.loadIndex : 4
NootedBlue    SYSLOG: @ kextG11HW.loadIndex : 5
NootedBlue    SYSLOG: @ kextG11HWT.loadIndex 7
NootedBlue    SYSLOG: @ kextG11FBT.loadIndex : 6
...

Lilu_1.6.9_23.6.txt

Edited November 5, 2024 by ASUS Vivobook

[Stezza88]

- With loaded (gen7TGL) com.xxxxx.driver.AppleIntelTGLGraphics", graphicsschedulerselect = 0

      -> framebuffer not loaded

      -> always 15 mb vrAM

      -> still no acceleration

      -> can't see [IGPU] logs in boot

 

Edited November 5, 2024 by ASUS Vivobook

[Stezza88]

[WEG] I'm understanding now that "-disablegfxfirmware" boot arg disable the possible scheduler selection so i cannot change scheduler.. but if i toggle this boot arg i obtain the consequent scheme :

 

------------ Resume ------------

Without boot arg -disablegfxfirmware

- boot arg igfxfw=2, kp "Firmware Load failed boot hash check!"

- boot arg igfxfw=1,

                       SCHEDULER 5 => gpu stall

                       SCHEDULER 4 => kp "guc binary load failure"

                       SCHEDULER 3 => kp "Firmware Load failed boot hash check!"

                       SCHEDULER 1 => kp "unsupported graphic scheduler select"

                       SCHEDULER 0 => kp "Firmware Load failed boot hash check!"

- boot arg igfxfw=0 / igfxfw=-1, gpu stall

---------------------------------

With -disablegfxfirmware

- gpu stall and no scheduler selection

---------------------------------

 

In weg src code we've got these cases, so i think i tryed everything.. with bad results.. I don't know what to choose as "the best of" XD

/**
*  GuC firmware loading scheme
*/
enum FirmwareLoad {
	FW_AUTO    = -1 /* Use as is for Apple, disable for others */,
	FW_DISABLE = 0, /* Use host scheduler without GuC */
	FW_GENERIC = 1, /* Use reference scheduler with GuC */
	FW_APPLE   = 2, /* Use Apple GuC scheduler */
};

Edited November 8, 2024 by ASUS Vivobook

[jalavoui]

yes since in linux your drivers loads firmware don't use -disablegfxfirmware. unless you wanna test scheduler 5

 

did you check wg firmware patches? they are for very old os x version

 

btw this didint panic. so the patch worked

 

Edited November 5, 2024 by jalavoui

[Stezza88]

Want to try to config better like linux configs the numofslices, etc in method getgpuinfo of weg.. maybe i can avoid the icl sku patching... but in weg i'm in doubt.. what is the best way i found second you? Just look above..

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

the icl sku check depends on ig-platform. i think you need to patch it. focus on framebuffer as graph kext only matter if framebuffer kexts loads

[Stezza88]

Just now, jalavoui said:

the icl sku check depends on ig-platform. i think you need to patch it. focus on framebuffer as graph kext only matter if framebuffer kexts loads

 

Never have a framebuffer loaded in all of this tests...

[Stezza88]

I found, for example, that all of these three patches f2, f2b, f1 cannot be found on IDA Pro byte searching in my appleinteliclgraphics binary

void IGFX::ForceCompleteModeset::processFramebufferKext(KernelPatcher &patcher, size_t index, mach_vm_address_t address, size_t size) {
	
	// AppleIntelFramebufferController::hwSetMode skip hwRegsNeedUpdate
	static const uint8_t f2[] = {0xE8, 0x31, 0xE5, 0xFF, 0xFF, 0x84, 0xC0, 0x74, 0x3D};
	static const uint8_t r2[] = {0xE8, 0x31, 0xE5, 0xFF, 0xFF, 0x84, 0xC0, 0xEB, 0x3D};
	
	// AppleIntelFramebufferController::hwSetMode skip hwRegsNeedUpdate - macOS Sonoma 14.x
	static const uint8_t f2b[] = {0xE8, 0x54, 0xEA, 0xFF, 0xFF, 0x84, 0xC0, 0x74, 0x5C};
	static const uint8_t r2b[] = {0xE8, 0x54, 0xEA, 0xFF, 0xFF, 0x84, 0xC0, 0xeb, 0x5C};

	// writeReg32(SOUTH_DSPCLK_GATE_D,PCH_GMBUSUNIT_CLOCK_GATE_DISABLE); Wa_14011294188:ehl,jsl,tgl,rkl,adl-s
	static const uint8_t f1[] = {0x74, 0x28, 0x48, 0xFF, 0x05, 0x9E, 0x65, 0x0B, 0x00, 0xBE, 0x20, 0x20, 0x0C, 0x00, 0x4C, 0x89, 0xEF, 0xE8, 0x3F, 0xE2, 0xFF, 0xFF, 0x0D, 0x00, 0x10, 0x00, 0x00};
	static const uint8_t r1[] = {0x90, 0x90, 0x48, 0xFF, 0x05, 0x9E, 0x65, 0x0B, 0x00, 0xBE, 0x20, 0x20, 0x0C, 0x00, 0x4C, 0x89, 0xEF, 0xE8, 0x3F, 0xE2, 0xFF, 0xFF, 0xb8, 0x00, 0x00, 0x00, 0x80};
	...
}

now the point is ... what the developer should have intention to do? How can I replace all of this absence of occurrency? You have a method ?

Edited November 5, 2024 by ASUS Vivobook

[jalavoui]

don't look at all those patches they were research work in ventura.

 

check the enabled patches as they work for some cards

 

system icl as only 1 active patch -  this changes card id check to match card id 0x9a49

 

 

+ the hwRegsNeedUpdate() patches which works for sonoma,etc

 

next you have some functions that are disabled and others that do simple things

 

maybe they work for your card but i think extra work will be needed

 

for your card maybe watch uint8_t f6[] = its the connectors patch

 

so the idea of nblue is do research and disable things that are no longer need but giving some tips to other devs

 

hope you can test all those framebuffers and make it work for you

 

btw the hwRegsNeedUpdate() in nblue as function name comment so search ghidra for function named hwRegsNeedUpdate

 

make sure you use PANIC_COND - this helps if you do a wrong patch or mistake

Edited November 5, 2024 by jalavoui

[Stezza88]

37 minutes ago, ASUS Vivobook said:

I found, for example, that all of these three patches f2, f2b, f1 cannot be found on IDA Pro byte searching in my appleinteliclgraphics binary

void IGFX::ForceCompleteModeset::processFramebufferKext(KernelPatcher &patcher, size_t index, mach_vm_address_t address, size_t size) {
	
	// AppleIntelFramebufferController::hwSetMode skip hwRegsNeedUpdate
	static const uint8_t f2[] = {0xE8, 0x31, 0xE5, 0xFF, 0xFF, 0x84, 0xC0, 0x74, 0x3D};
	static const uint8_t r2[] = {0xE8, 0x31, 0xE5, 0xFF, 0xFF, 0x84, 0xC0, 0xEB, 0x3D};
	
	// AppleIntelFramebufferController::hwSetMode skip hwRegsNeedUpdate - macOS Sonoma 14.x
	static const uint8_t f2b[] = {0xE8, 0x54, 0xEA, 0xFF, 0xFF, 0x84, 0xC0, 0x74, 0x5C};
	static const uint8_t r2b[] = {0xE8, 0x54, 0xEA, 0xFF, 0xFF, 0x84, 0xC0, 0xeb, 0x5C};

	// writeReg32(SOUTH_DSPCLK_GATE_D,PCH_GMBUSUNIT_CLOCK_GATE_DISABLE); Wa_14011294188:ehl,jsl,tgl,rkl,adl-s
	static const uint8_t f1[] = {0x74, 0x28, 0x48, 0xFF, 0x05, 0x9E, 0x65, 0x0B, 0x00, 0xBE, 0x20, 0x20, 0x0C, 0x00, 0x4C, 0x89, 0xEF, 0xE8, 0x3F, 0xE2, 0xFF, 0xFF, 0x0D, 0x00, 0x10, 0x00, 0x00};
	static const uint8_t r1[] = {0x90, 0x90, 0x48, 0xFF, 0x05, 0x9E, 0x65, 0x0B, 0x00, 0xBE, 0x20, 0x20, 0x0C, 0x00, 0x4C, 0x89, 0xEF, 0xE8, 0x3F, 0xE2, 0xFF, 0xFF, 0xb8, 0x00, 0x00, 0x00, 0x80};
	...
}

now the point is ... what the developer should have intention to do? How can I replace all of this absence of occurrency? You have a method ?

 

These were from weg.. this Is a mixture topic XD

 

Btw i understand the principles of nblue.. Hope to have some more luck too..

Edited November 5, 2024 by ASUS Vivobook

[Stezza88]

Should be useful to have also the boot [IGPU] logs in system log files.. they are too fast sometimes and cannot see those in system logs.. uff

Edited November 5, 2024 by ASUS Vivobook

[Stezza88]

2 hours ago, jalavoui said:

don't look at all those patches they were research work in ventura.

 

check the enabled patches as they work for some cards

 

system icl as only 1 active patch -  this changes card id check to match card id 0x9a49

 

 

+ the hwRegsNeedUpdate() patches which works for sonoma,etc

 

next you have some functions that are disabled and others that do simple things

 

maybe they work for your card but i think extra work will be needed

 

for your card maybe watch uint8_t f6[] = its the connectors patch

 

so the idea of nblue is do research and disable things that are no longer need but giving some tips to other devs

 

hope you can test all those framebuffers and make it work for you

 

btw the hwRegsNeedUpdate() in nblue as function name comment so search ghidra for function named hwRegsNeedUpdate

 

make sure you use PANIC_COND - this helps if you do a wrong patch or mistake

 

These patches are for ICLLP.. ICLLP not works to me... boot stall and gpu goes in overheat..