[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

[ArtikDiamond]

14 hours ago, Mastachief said:

Compile nblue, added latest hookcase to /L/E

Added sle kexts to S/L/E after breaking system seal including bundles.

Enable the tglframebuffer in nblue info.plist, I nulled the others....

Same

[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 October 31 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 October 31 by jalavoui

[Visual Ehrmanntraut]

I was talking about __GLOBAL__sub_I_AppleIntelOSInfoList.cpp.

On 10/30/2024 at 9:59 PM, jalavoui said:

 

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

 

14 hours ago, jalavoui said:

anyway this can be related with this patch in nblue

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

The "this" pointer in C++ can't be null. Something else is going wrong here.

[jalavoui]

yep that was my idea. i think the value that is passed is wrong

 

looking at a working log from the web there seems tobe some call to agdc to ativate port

 

 

that's why i asked you to unscramble some of the code

 

tgl as a ADD ECX,-0x3 while icl driver uses ADD ECX,-0x2 - this might matter

this is a simple issue idk why i'm taking so long to solve it

 

hmmm dam tgl

 

so goal is this

Edited November 1 by jalavoui

[jalavoui]

just splited the code of tgl for debug and production versions. to enable/disable the patches in nblue just use the //PANIC_COND(!LookupPatchPlus

 

x.log.zip

 

so this will enable debug version

 

otherway around for production version patches

 

prod version seems to have less code maybe cause of isDSCSupported() i.e., DSC displays

Edited November 1 by jalavoui

[jalavoui]

this is the random kp at nblue. think i trace it

 

also found a wrong register reading

 

 

Edited November 1 by jalavoui

[Visual Ehrmanntraut]

btw, this code isn't optional at all
 

[jalavoui]

that was cause of a kp with tgl production version. will check later

 

atm this kp at this address is very strange

 

 

i think tgl doesnt like me

 

i'm playing with debug version atm and

IOReturn AppleIntelBaseController::hwSetupDSBMemory()

is fine. gonna test production version also

 

gonna upload hookcase with removed return 0 b4 i forget doing it

 

meanwhile

before any call to register32 this always kp. so i'll just the powerwell patches and ignore probeportmode()

 

 

Edited November 1 by jalavoui

[Visual Ehrmanntraut]

1 minute ago, jalavoui said:

that was cause of a kp with tgl production version

the code and information I give you is based on the production version 😵‍💫

2 minutes ago, jalavoui said:

i think tgl doesnt like me

Sure seems like it 🙂

[jalavoui]

well if i keep coding like this....

 

 

next crash is before the readreg (highlighted). making the transcoderoffet() return zero won't allow the call to readreg to proceed

 

 

from here i'll have to aplly bypass patchs and ofc it avoids kp but don't really fix the issues

anyway at this stage, and forward the code depends on port reading values

Edited November 1 by jalavoui

[jalavoui]

debug version as agdc code that was removed from production

this kp is from trying to disabled agdc calls on debug version

 

 

ffff @$%&! this

 

updated nblue for both tgl - the reg validation helped a bit

 

next step

 

check AppleIntelFramebuffer::enableController(void) for port reading values as they are used on readreg32

e.g the offset depends on var8 - wrong values and the code fails

Edited November 1 by jalavoui

[Visual Ehrmanntraut]

2 hours ago, jalavoui said:

e.g the offset depends on var8 - wrong values and the code fails

I think found the issue, they forgot to do this->fRegAccessManager = controller->fRegAccessManager.
0x4a40 is the offset in AppleIntelFramebuffer
add the missing code in AppleIntelFramebuffer::init ( __ZN21AppleIntelFramebuffer4initEP31AppleIntelFramebufferControllerj )
fn AppleIntelFramebuffer::init(this: *mut AppleIntelFramebuffer, controller: *mut AppleIntelFramebufferController, arg3: u32) -> bool
getMember(this, 0x4A40) = getMember(controller, 0xC40);

[jalavoui]

is this correct? void*  to void *

 

ghidra is giving me other types

 

Edited November 1 by jalavoui

[Visual Ehrmanntraut]

Yes

[jalavoui]

hmmm result from production with only 

 

this are port count 9 to 3 patch (f2p)

powerwell patches to probeportmode() (13p and 13pb)

and getHPDState() address patch (f19)

 

zero functions patched only this 1 active

 

forgot the stolen mem patch. is also active (ported from wg code as production complains of low stolen memory)

 

 

 

gonna try something

Edited November 1 by jalavoui

[Visual Ehrmanntraut]

Same issue again but with AppleIntelPlane

Doesn't even pass the controller to this one, you'll need to store the controller this pointer by wrapping AppleIntelFramebufferController::start ( __ZN31AppleIntelFramebufferController5startEP9IOService ) then before calling org storing the this pointer somewhere. Then in AppleIntelPlane::init ( __ZN15AppleIntelPlane4initE9IGPlaneID ) store fRegAccessManager from the controller into offset 0x90 in the this pointer of the plane

These drivers really are unfinished and it shows.

 

[Visual Ehrmanntraut]

Wait, you can access _gController, no need for the wrap.

e.g.

[jalavoui]

yep the production version seems to lack code. that's why i also look at debug version but maybe same {censored}

 

i kinda doubt they be so lazy to make the code break at such early stage

 

gonna recheck again where it starts failing

 

sadly if you have the hardware i bet you will find the issue in 1 day

 

i know the very 1st panic is at powerwell::init with that call to probeportmode() gonna ignore it for now

 

k so with this the 1st kp is same as posted here

 

intel ports are tricky. this tgl as 9 connectors. the f2p patch only allows first 3 tobe used

 

 

Edited November 2 by jalavoui

[Visual Ehrmanntraut]

8 minutes ago, jalavoui said:

yep the production version seems to lack code. that's why i also look at debug version but maybe same {censored}

Nope, the opposite. I just inspected the diags version, and it seems has the same issue with missing assignments for the register access manager. It likely just breaks earlier.

14 minutes ago, jalavoui said:

i kinda doubt they be so lazy to make the code break at such early stage

Sounds to me more like they stopped working on the driver in the middle of development of Big Sur, likely after failing to negotiate with Intel or deciding to dump Intel for ARM.

[Visual Ehrmanntraut]

27 minutes ago, jalavoui said:

sadly if you have the hardware i bet you will find the issue in 1 day

I'm no magician, it would take longer than that, but thanks. Unrelated, but I am cooking up something very spicy that's GPU-related.