Jump to content

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


shl628
716 posts in this topic

Recommended Posts

gonna leave the bins untouched on other thread till we find something better

i'm loking at nvram and cameliia (china) registers

 

added saved-config var to nblue sources + savednvram patch for kernel call

 

masta can you test it?

 

what happens if you disable the applebacklight ?. the displays gets full brightness?

Edited by jalavoui
Link to comment
Share on other sites

This boot is using the updated nblue source, just disabled net and compiled, didnt edit connectors as it gives a hang.

Boots the same as before at half brightness.

The pnlf is disabled, you can check my config.plist in the github, however, it's still half brightness.
 
hackintool boot.logHackintool system.log



Link to comment
Share on other sites

5 hours ago, jalavoui said:

Xe IGPU (0x46a6) is kinda same family as asus laptop (check his thread)

from is logs i think is doable - load adl in tgl framebuffer.

the connector patch you mentioned is so easy todo using nblue (conn zero). but i think other issues will pop up

don't think at 0x9a49 as a limitation. it is the way i foud out to link tgl settings with tgl fram kext graphics kext.

waht really makes the driver works are the patches

 

idk what you guys need todo it but we here to help

Thanks, and it's much appreciated. Apologies in advance if anything I say or do is noob-level, as I'm out of my comfort zone here.

 

I have finally successfully managed to build the first working kext for NootedBlue that loads, at least I think it does, but framebuffer still shows 8MB (so I guess framebuffer not correct). But it doesn't KP anymore with Unsupported ICL Sku, so something is done right atm.

 

Things I've only changed so far:

 

static uint8_t builtin[] = {0x00};		
static uint8_t builtin2[] = {0x00, 0x00, 0x05, 0xFF}; // this ICL framebuffer worked for me with WG, am assuming I should test with this?
static uint8_t builtin3[] = {0xA6, 0x46, 0x00, 0x00}; // my native device-id, should I still keep this enabled?

 

Other points worth of note:

 

AAPL,ig-platform-id set to 000005FF.

Connectors in DeviceProperties set just as my github (9520)

 

 

Julian's XPS 9520 Macbook Air - NootedKextLoaded.ioreg.zip

Edited by jkbuha
Link to comment
Share on other sites

in theory having the device id match ig-platform helps loading the acelerator due to internal checkings. hope you also follow asus work he is almost done loading tgl.

 

to load the system icl frame you need to swap card-ids in nblue info.plist. it is defaulted to TGLle

ICLle is debug version from DTK and is installed to /L/E

Gen7 are the acelerators.

if you add a card-id to any of this properties and the kext fails to load you might get a boot hang

 

image.png.81bde4b42ad5b1c31186c56549173968.png

 

from what you're saying i would go for TGLle as icl is bit old for our cards

and btw you dont need to inject anything (in theory) with OC

 

your ssdtd are so good i'm review mines.

noticed you dont have this. think it is needed for intel graph kexts

image.thumb.png.7f07e2af99accd65e1d41daca09d90e1.png

 

+ the classic

image.png.415581d6116ee6853c7196678a605474.png

Edited by jalavoui
  • Thanks 1
Link to comment
Share on other sites

On 5/14/2024 at 3:15 PM, Mastachief said:

On Dortiana's Github guide page, look for the Patching Bus IDs page, however the patch shown is not with IceLake, I am going to use the icelake framebuffer below as an example though.

ID: 8A510002, STOLEN: 64 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000E304
TOTAL STOLEN: 193 MB?, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 193 MB, MAX OVERALL: 194 MB (203960320 bytes)
Model name: Intel Iris Plus Graphics
Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 0, type: 0x00000002, flags: 0x00000018 - ConnectorLVDS
[2] busId: 0x09, pipe: 1, type: 0x00000400, flags: 0x000002C1 - ConnectorDP
[3] busId: 0x0A, pipe: 1, type: 0x00000400, flags: 0x000002C1 - ConnectorDP
00000000 00000000 00000000 00000000 02000000 18000000
02000000 09000000 01000000 01000000 00040000 C1020000
03000000 0A000000 01000000 01000000 00040000 C1020000

 

Les analyze the first line for use with the alldata method;

[0] busId: 0x00, pipe: 0, type: 0x00000002, flags: 0x00000018 - ConnectorLVDS  00000000 00000000 00000000 00000000 02000000 18000000 

I have a few notes below, if you put the original values into a table to break down what they are saying using "00000000 00000000 00000000 00000000 02000000 18000000"

 

Bit

 

Name

 

Value

 

Bit 1

Port

0

Bit 2

Bus ID[SM1] 

0

Bit 3-4

Pipe Number

0000

Bit 5-8

Connector Type

02000000

Bit 9-12

Flags

18000000


 [SM1] BusID is a unique value and cannot be used by multiple entries

 

This is the portion that will be used in setting up the framebuffer for a specific connector, see below for the ioreg that is currently shown when i boot currently using the whenvergreen attached.

 

image.png.2a0dd2d615edd7fc2c168c7ae81b313f.png

 

For the GPU the "display0' is being seen under AppleIntelFramebuffer@1 instead of AppleIntelFramebuffer@0, when jala did the changes, he was able to get this change done using nblue, but there were issues.

 

image.thumb.png.1199519aaad9bdb983cb5aa5234fe22f.png

 

The method was to setup the framebuffer-con0-XXXX settings that are needed using the alldata method

 

image.thumb.png.105b2160bfab626212a55c51107823ec.png

 

Do note that there are three (3) framebuffers  however it is numbered 0, 1, 2, 3 , example AppleIntelFramebuffer@0, AppleIntelFramebuffer@1, AppleIntelFramebuffer@2. You have to then disable framebuffer-con0-alldata and framebuffer-con2-alldata and framebuffer-con3-alldata, by zeroing the bus id on those specific indexes, example for AppleIntelFramebuffer@2 below;

03000000 00000000 01000000 01000000 00040000 C1020000

You should also then do the same for framebuffer-con0-alldata and framebuffer-con3-alldata

 

image.thumb.png.2f5a542e1d30e609e18256f75ae4c5d8.png

 

you will then have the framebuffers in your device properties section for the IGPU,

 

the index explanation

 

Port: Port is Index number, its usually 0 only for the internal GPU

Bus ID: Bus ID is the bus that the device is attached to

Pipe Number: Dont know, read the info that comes up when you hover over the value while using hackintool

 

image.png.4a592cdc540a470f69c715cc92c96a6f.png

 

Connector Type: a value that is generated based on the ticked options in hackintool under the patch tab and the connectors sub menu, a list taken from Dortiana is below.

<02 00 00 00>        LVDS and eDP      - Laptop displays
<10 00 00 00>        VGA               - Unsupported in 10.8 and newer
<00 04 00 00>        DisplayPort       - USB-C display-out are DP internally
<01 00 00 00>        DUMMY             - Used when there is no physical port
<00 08 00 00>        HDMI
<80 00 00 00>        S-Video
<04 00 00 00>        DVI (Dual Link)
<00 02 00 00>        DVI (Single Link)

 

image.png

 

This Is a good piece of thread for me..

  • Thanks 1
Link to comment
Share on other sites

I did another post after that with a device properties config that had all the connectors set where I then had the display connected under framebuffer 0 using whatevergreen, it had the entire set of values to be used using the all data method.

However when I tried to replicate this connector values to the first 3 connectors in the latest iteration of nooted blue, it gave a hang on boot, I should investigate just be sure.

Link to comment
Share on other sites

indeed masta

let me check for the properties in tgl driver. i remenber saw then

 

so nblue as 3 connectors that you can overwrite using opencore. most important is con zero - make the lcd display work

i don't remenber this flags but wg as docs about them

so AAPL00,override will alow edid injection - not sure which1

hope you can find something about this

 

all this flags are read by the tgl driver. this is nice cause we can inject panel power cycle delay from linux values

and maybe help on backlight support using camellia and banksia code

 

image.png.5acc966aea68bd807bc998fbf7341c39.png

 

messing with this port really brings lots of hangs/broken display. i've tested some changes and it only gets worst

image.thumb.png.1980832d7bceab2cacf1eef2d8780985.png

 

Edited by jalavoui
Link to comment
Share on other sites

image.png.4b93524c83e3a2b1cb06cc92a8a1d625.png

 

from here?

/* WaEnableChickenDCPR:skl,bxt,kbl,glk,cfl */

intel_uncore_rmw(&i915->uncore, GEN8_CHICKEN_DCPR_1, 0, MASK_WAKEMEM);

 

this register "fix" also used in...

void AppleIntelPowerWell::enableDisplayEngine(void)

 

but they say

image.png.9936de715b8c3af44ccecbe99e2fdd18.png

code from 1969

Edited by jalavoui
Link to comment
Share on other sites

Well, something is setting the brightness to mid brightness on boot when using either Production/Debug.

 

Look in my github, it had the registers i wrote to in my tests.

 

ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8254
                                    (0x000c8254): 0x00017700 (freq 1, cycle 30464)
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8254
                                    (0x000c8254): 0x00017700 (freq 1, cycle 30464)
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00047700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00037700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00012700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8255 0x00012700
                                    (0x000c8255): 0xfd000177
                                    (0x00012700): 0x00000000
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8253 0x00012700
                                    (0x000c8253): 0x0000fd80
                                    (0x00012700): 0x00000000
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8256 0x00012700
                                    (0x000c8256): 0x00fd0001
                                    (0x00012700): 0x00000000
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8257 0x00012700
                                    (0x000c8257): 0x0000fd00
                                    (0x00012700): 0x00000000
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8258 0x00012700
                                    (0x000c8258): 0x0000b6d3
                                    (0x00012700): 0x00000000
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8253 0x00012700
                                    (0x000c8253): 0x0000fd80
                                    (0x00012700): 0x00000000
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8254
                                    (0x000c8254): 0x00017700 (freq 1, cycle 30464)
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8255
                                    (0x000c8255): 0xfd000177
ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8255
                                    (0x000c8255): 0xfd000177

TIme to whip out the old Ubuntu USB, got to edit my grub to grab debug, which Glavor GNU/Linux and Kernel are you using to pull your info Jala? Wanna be as close as possible in producing results.

 

or did you just use the lastest driver with the current Kernel? like this one ---> https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2024-2/rebuild-and-install-i915-module-ubuntu.html

 

 

 

Edited by Mastachief
Link to comment
Share on other sites

masta any linux is fine. just make sure you update the linux kernel

 

maye the inital tgl code works partial for your display

 

one of this calls ?

 

image.png.626cc31a5cd20edbf220392c208695ef.png

 

you can try hack this condition for testing. there's a banksia conditon also available at

AppleIntelBaseController::start(AppleIntelBaseController *this,IOService *param_1)

image.png.dec53d14083bd8eb28b401153ef41987.png

 

you can also try to inject the value maybe at new workarounds call function from nblue

 

this is disabled by default in nblue. i enabled and got the backlight slider working. the range needs a fix

image.png.024a1d4623627fb44dcd14ab3e07f60c.png

 

Edited by jalavoui
Link to comment
Share on other sites

Putting some info here in case i lose it.

 

macOS has its own graphics drivers, which often abstract direct hardware register access. The macOS drivers (like AppleIntelFramebuffer or AppleIntelGraphics) typically interact with the GPU through Apple’s APIs and might not expose registers in the same way that the i915 driver does on Linux.


Because of this, we might not have direct access to these registers in macOS as you would with Linux’s intel_reg tool.

 

the memory maps are resovled to MMIO region....

 

i915_boot_log.zip

 

i915_dmesg_log.txt

 

all_registers.txt

 

0000:00:02.0.zip

 

ACPI.zip

 

xrandr verbose info.txt

 

 

 

 

Edited by Mastachief
  • Like 3
Link to comment
Share on other sites

changed the sources to allow using the internal panel code. it is disabled by default on tgl debug section.

 

masta that bin is old

 

can you test nblue internal panel code?

enable

image.png.6b4b207e905f01e6c2b2009af9d6bf74.png

and disable patch f10 in

image.png.6eb47e28ddbfdc09f7430119a944fa5a.png

Edited by jalavoui
Link to comment
Share on other sites

×
×
  • Create New...