Jump to content

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


shl628
606 posts in this topic

Recommended Posts

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
image.png.dd3476edfc62c399e4accba603458f17.png
 
this is enabled
image.png.6b810702a3091c501cc99a20b7fda7be.png
 
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?
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Capturadeecra2024-10-31as22_17_37.png.0655cb6e9f2cf4ae09d6ff3eb724f692.png

 

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

Capturadeecra2024-10-31as22_23_24.png.76e8e0c85ff68bc1b00ca91577ff14b9.png

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)

Capturadeecra2024-10-31as22_42_32.png.19fd6582748a824c3a9758449786d006.png

 

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

image.png.cd37a4798f32998813b05064caebc053.png

 

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

image.thumb.png.4a3cefaf6c50da79e32e99aa0999a293.png

 

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

image.thumb.png.e99fb5b4286d2883c2b7de755e27b102.png

Edited by jalavoui
Link to comment
Share on other sites

×
×
  • Create New...