[80% Solved] Iris Xe iGPU on Tiger Lake successfully loaded ICLLP Frambuffer and VRAM also recognizes 1536MB! + However, some issues.

[Visual Ehrmanntraut]

19 hours ago, jalavoui said:

this is the function that allows changing some setings. seems disabled in production version as lilu patches don't work

global initialiser function, called at load of the kernel module, likely too early for lilu

[jalavoui]

hookcase doesnt use lilu and other functions work (like readreg, etc).

 

but you might have solved a random nblue start() error. i've disabled this extra calls that aren't used

 

[Mastachief]

that kp is cause icl code is for ventura. but 
in 
if (kextG11FB.loadIndex == index) {
 
you can try changing PANIC_COND to SYSLOG_COND 
 
this are for testing system icl
 
its a bad idea but might work.
 
you should try iclLE or tglLE - no need patches as theyre from DTK
 
kp on paches should have this log line
"nblue","Failed to route symbols"
when u reboot to mac os
 
gonna test other icl as i was checking tgl production
 
k so sys icl works on ventura but i forgot i'm using an old release. anyway only 1 patch is ative. possible kp on other os x versions are on function calls.
 
iclLE passed the test
 
tglLE production i changed nothing so should be fine. passed test
 
only possible thing to watch is void NBlue::processPatcher(KernelPatcher &patcher)
mem detection might be broken for you or someting else in there
 
your kext setup seems fine
 
as for nblue info.plist
to disable a kext in nlbue just use a empty id on the frame you dont wanna use
fill it with card ids otherwise (only 1 frame can be active)
other ways of disabling might not work
this is disabled

 
this is enabled

 
as for the kexts installed in /L/E or /S/L/E i set a invalid 0x12348086 so os x dont load them. nblue is ment todo it not os x by itself

Don't you need to change the xxxxx to apple along when adding the PCI id's or replacing the 0x12348086?

[jalavoui]

xxxxx is the renamed driver name! don't mess with it

Edited 5 hours ago by jalavoui

[Visual Ehrmanntraut]

2 hours ago, jalavoui said:

hookcase doesnt use lilu and other functions work (like readreg, etc).

ok, and? these functions are called as soon as the kext gets loaded. what you're trying to do would be the equivalent of escaping from JavaScript Sandbox to hijack the JavaScript Sandbox initialisation function; it's already been called long before you get a chance to actually hijack it.

[jalavoui]

visual you misunderstood what i sayd.

 

check this code at tgl framebufer production version - the call is probeportmode() returned from hookcase.

it always crashes after returning from hookcase - kernel panic at 0x0005a40d

i tryed making probeportmode() to return 1 to check with simple value and still crashes

 

i look at the code and because of the kp i just patched it to avoid using hookcase()

so you agree this is not lilu related ?

what else can it be?

 

2nd panic related with probeportmode() also here (also patched to avoid kp)

 

i consider this small bugs but atm they are preventing the driver to load correctly

 

anyway this can be related with this patch in nblue

i just can't get rid of this "validation" hack

 

can you unscramble this part of code ? i need to know what is happening here cause it is related with probeportmode() code

 

icl as a similiat china code that i can't decompile better

Edited 1 hour ago by jalavoui