Visual Ehrmanntraut Posted 9 hours ago Share Posted 9 hours ago 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 Link to comment Share on other sites More sharing options...
jalavoui Posted 7 hours ago Share Posted 7 hours ago 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 Link to comment Share on other sites More sharing options...
Mastachief Posted 6 hours ago Share Posted 6 hours ago 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 itselfDon'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 More sharing options...
jalavoui Posted 5 hours ago Share Posted 5 hours ago (edited) xxxxx is the renamed driver name! don't mess with it Edited 5 hours ago by jalavoui Link to comment Share on other sites More sharing options...
Visual Ehrmanntraut Posted 4 hours ago Share Posted 4 hours ago 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 More sharing options...
jalavoui Posted 2 hours ago Share Posted 2 hours ago (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts