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

Mastachief · April 4

22 hours ago, jalavoui said:

update

not panic on patches make them not tobe applyed bylilu. so they need tobe separated

So I should use Fake SMC then?

Slice · April 4

22 minutes ago, Mastachief said:

So I should use Fake SMC then?

It is always good idea.

jalavoui · April 5

found the bug. the arrays need tobe same size for this to work. this code fails

LookupPatchPlus const patchesc[] = {

{&kextG11FB, f, r, arrsize(f), 1},

{&kextG11FB, f3, r3, arrsize(f3), 1},

};

LookupPatchPlus const patches[] = {

//{&kextG11FB, f, r, arrsize(f), 1},

{&kextG11FB, f2, r2, arrsize(f2), 1},

};

auto catalina = getKernelVersion() == KernelVersion::Catalina;

SYSLOG_COND(!LookupPatchPlus::applyAll(patcher, catalina ? patchesc:patches , address, size), "gen11", "Failed to apply patches!");

so just use this

auto catalina = getKernelVersion() == KernelVersion::Catalina;

if (catalina)

SYSLOG_COND(!LookupPatchPlus::applyAll(patcher, patchesc , address, size), "gen11", "Failed to apply patches!");

else

SYSLOG_COND(!LookupPatchPlus::applyAll(patcher, patches , address, size), "gen11", "Failed to apply patches!");

i just tested catalina and idk if it updated itself but the patches aren't working

anyway goal is focus on ventura so nvm

AND IT'S ALWAYS BETTER TO USE PANIC_COND cause it panic if patches aren't applyed

left is cata log and right is ventura

if the patch is applyed then the modeset by scaler is called and the screen won't turn black.

if the patch fails then you get complete modeset and a black screen

this works in the cata installer but not after os is installed...

maybe cause i have ventura and cata on same disk ?

confirmed - i just patched the binay on disk and it works

howto?

in cata mount uw / as root

patch the framebuffer file

force kextcache to rebuild

side effect - need to bring back SYSLOG_COND to avoid panic for cata

Edited April 10 by jalavoui

benmacfreak · April 5

2 hours ago, jalavoui said:

found the bug. the arrays need tobe same size for this to work. this code fails

LookupPatchPlus const patchesc[] = {

{&kextG11FB, f, r, arrsize(f), 1},

{&kextG11FB, f3, r3, arrsize(f3), 1},

};

LookupPatchPlus const patches[] = {

//{&kextG11FB, f, r, arrsize(f), 1},

{&kextG11FB, f2, r2, arrsize(f2), 1},

};

auto catalina = getKernelVersion() == KernelVersion::Catalina;

SYSLOG_COND(!LookupPatchPlus::applyAll(patcher, catalina ? patchesc:patches , address, size), "gen11", "Failed to apply patches!");

so just use this

auto catalina = getKernelVersion() == KernelVersion::Catalina;

if (catalina)

SYSLOG_COND(!LookupPatchPlus::applyAll(patcher, patchesc , address, size), "gen11", "Failed to apply patches!");

else

SYSLOG_COND(!LookupPatchPlus::applyAll(patcher, patches , address, size), "gen11", "Failed to apply patches!");

i just tested catalina and idk if it updated itself but the patches aren't working

anyway goal is focus on ventura so nvm

AND IT'S ALWAYS BETTER TO USE PANIC_COND cause it panic if patches aren't applyed

left is cata log and right is ventura

if the patch is applyed then the modeset by scaler is called and the screen won't turn black.

if the patch fails then you get complete modeset and a black screen

so what's that mean? we're screwed or?

Mastachief · April 5

Are you using Ventura 13.6.5 or 13.6.6?

The issue I was highlighting in my previous image was when using Ventura 13.6.5 with a similar configuration to yours, it differs slightly because of Dell hardware need some extra quirks smbiosguid etc

Also can you share the plist that you are using to boot ventura currently? Not sure if you are using the same plist as a couple posts up.

jalavoui · April 5

latest ventura always. yes i'm using same oc config

logs from vent and cata (with and without the binary patch)

i see a lot of bugs but guess can be ignored as the framebuffer is working

logs.zip

i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)

static void dmc_load_work_fn(struct work_struct *work)
{
	struct intel_dmc *dmc = container_of(work, typeof(*dmc), work);
	struct drm_i915_private *i915 = dmc->i915;
	const struct firmware *fw = NULL;
	const char *fallback_path;
	int err;

	err = request_firmware(&fw, dmc->fw_path, i915->drm.dev);

	if (err == -ENOENT && !i915->params.dmc_firmware_path) {
		fallback_path = dmc_fallback_path(i915);
		if (fallback_path) {
			drm_dbg_kms(&i915->drm, "%s not found, falling back to %s\n",
				    dmc->fw_path, fallback_path);
			err = request_firmware(&fw, fallback_path, i915->drm.dev);
			if (err == 0)
				dmc->fw_path = fallback_path;
		}
	}

	parse_dmc_fw(dmc, fw);

	if (intel_dmc_has_payload(i915)) {
		intel_dmc_load_program(i915);
		intel_dmc_runtime_pm_put(i915);

		drm_info(&i915->drm, "Finished loading DMC firmware %s (v%u.%u)\n",
			 dmc->fw_path, DMC_VERSION_MAJOR(dmc->version),
			 DMC_VERSION_MINOR(dmc->version));
	} else {
		drm_notice(&i915->drm,
			   "Failed to load DMC firmware %s."
			   " Disabling runtime power management.\n",
			   dmc->fw_path);
		drm_notice(&i915->drm, "DMC firmware homepage: %s",
			   INTEL_UC_FIRMWARE_URL);
	}

	release_firmware(fw);
}

so this code

if (intel_vgpu_active(i915)) {

drm_notice(&i915->drm,

"%s, disabling use of stolen memory\n",

"iGVT-g active");

return -ENOSPC;

}

if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 😎 {

drm_notice(&i915->drm,

"%s, disabling use of stolen memory\n",

"DMAR active");

return -ENOSPC;

}

better to disable intel vt-d in bios ?

or keep it no issues

linux as a few if conditions when this is enabled

this error

  uVar7 = ReadRegister32(in_RDI,0x1082c0);
  uVar7 = uVar7 >> 7 & 3;
  iVar8 = 0x800000;
  if (uVar7 != 3) {
    iVar8 = *(int *)(&DAT_0009b090 + (ulong)uVar7 * 4);
    *(long *)(&PTR_DAT_000d3030)[uVar7] = *(long *)(&PTR_DAT_000d3030)[uVar7] + 1;
  }
  uVar7 = *(uint *)(in_RDI + 0xd7c);
  uVar11 = *(int *)(in_RDI + 0xd74) * 0x80000;
  *(uint *)(in_RDI + 0xd60) = uVar11;
  *(ulong *)(in_RDI + 0xd58) = (ulong)uVar7;
  puVar6 = PTR__page_size_000cf100;
  iVar1 = *(int *)PTR__page_size_000cf100;
  *(int *)(in_RDI + 0xd70) = *(int *)(in_RDI + 0xcf4) * iVar1;
  *(ulong *)(in_RDI + 0xd68) = (ulong)uVar11 + (ulong)uVar7;
  *(uint *)(in_RDI + 0xd90) = uVar11 + uVar7 + *(int *)(in_RDI + 0xcf4) * iVar1;
  uVar11 = *(uint *)(in_RDI + 0xd80);
  if (in_RDI[0x1ab0] == (AppleIntelFramebufferController)0x0) {
    uVar14 = 0;
  }
  else {
    _DAT_000e1b70 = _DAT_000e1b70 + 1;
    if (in_RDI[0x1ab2] == (AppleIntelFramebufferController)0x0) {
      puVar12 = (uint *)(*(long *)(in_RDI + 0xcd8) + 0x18);
    }
    else {
      _DAT_000e1b78 = _DAT_000e1b78 + 1;
      puVar12 = (uint *)(in_RDI + 0x1ab4);
    }
    uVar14 = *puVar12;
  }
  iVar13 = uVar14 + uVar11 + iVar1;
  uVar16 = iVar8 + iVar13;
  if (uVar7 < uVar16) {
    _DAT_000e1b80 = _DAT_000e1b80 + 1;
    _kprintf("[IGFB][ERROR][%-10s] Insufficient stolen memory\n","DISPLAY");

happens if iVar8 = 0x800000; or if reading

#define GEN6_STOLEN_RESERVED _MMIO(0x1082C0) is not 3

this values are also taken from ig-platform ids

#define GEN8_STOLEN_RESERVED_1M		(0 << 7)
#define GEN8_STOLEN_RESERVED_2M		(1 << 7)
#define GEN8_STOLEN_RESERVED_4M		(2 << 7)
#define GEN8_STOLEN_RESERVED_8M		(3 << 7)

drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);

	switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
	case GEN8_STOLEN_RESERVED_1M:
		*size = 1024 * 1024;
		break;
	case GEN8_STOLEN_RESERVED_2M:
		*size = 2 * 1024 * 1024;
		break;
	case GEN8_STOLEN_RESERVED_4M:
		*size = 4 * 1024 * 1024;
		break;
	case GEN8_STOLEN_RESERVED_8M:
		*size = 8 * 1024 * 1024;
		break;
	default:
		*size = 8 * 1024 * 1024;
		MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
	}

	if (HAS_LMEMBAR_SMEM_STOLEN(i915))
		/* the base is initialized to stolen top so subtract size to get base */
		*base -= *size;
	else
		*base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;

this backlight code is family specific (might disable for some lcds)

  iVar3 = AppleIntelFramebufferController::ReadRegister32
                    ((AppleIntelFramebufferController *)in_RDI[10],0xc7200);
  if (iVar3 < 0) {
    local_28 = CONCAT44(local_28._4_4_,0xdeadbeef);
    iVar3 = AppleIntelPort::readAUX((AppleIntelPort *)in_RDI[0xc],0,&local_28,4);
    if (iVar3 == 0) {
      _DAT_000ee318 = _DAT_000ee318 + 1;
      if (((int)local_28 == 0x41840a11) ||
         (_DAT_000ee320 = _DAT_000ee320 + 1, (int)local_28 == 0x41c41412)) {
        *(code **)(in_RDI[10] + 0x14f8) = CamelliaBase::_CheckCacheCallback;
        _DAT_000edc80 = _DAT_000edc80 + 1;
        *(undefined2 *)(in_RDI + 0x2b) = 0xffff;
        *(undefined *)((long)in_RDI + 0x69) = 1;
        cVar2 = CamelliaBase::IsThisBanksia();

on my dispay it gives _kprintf("[IGFB][ERROR][%-10s] TCON: Aux not ready at HW\n","PANEL");

there are some propertires common to this

#define INTEL_ICL_11_IDS(info) \

INTEL_ICL_PORT_F_IDS(info), \

INTEL_VGA_DEVICE(0x8A51, info), \

INTEL_VGA_DEVICE(0x8A5D, info)

INTEL_ICL_11_IDS(&icl_info),

INTEL_TGL_12_IDS(&tgl_info),

also

static const struct intel_device_info tgl_info = {

GEN12_FEATURES,

PLATFORM(INTEL_TIGERLAKE),

.platform_engine_mask =

BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),

};

static const struct intel_device_info icl_info = {

GEN11_FEATURES,

PLATFORM(INTEL_ICELAKE),

.platform_engine_mask =

BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),

};

ID: 8A5D0001, STOLEN: 64 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000A300  
TOTAL STOLEN: 193 MB?, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 193 MB, MAX OVERALL: 194 MB (203960320 bytes)  
Model name: Intel HD Graphics ICL RVP BigSur  
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 

ID: 8A510001, 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 HD Graphics ICL RVP BigSur  
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  

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

Edited April 6 by jalavoui

jalavoui · April 6

this is intel way of assign metal family (rip amd)

atm nblue doesnt have framebuffer injection properties like busid, etc

but the info.plist allows changing a few properties

i'll try add a section to allow changing framebuffer properties kinda like whatevergreen

this are the base values

image.png.92064271b0d485914c2262b38ea3ac53.png

altough no acceleration and wrong connectors this release is fine

need others to change it for non working displays

current boot flag: -v

Edited Wednesday at 06:30 PM by jalavoui

Mastachief · April 7

When booting the Ventura 13.6.5 Installer using the latest nblue kext, it gives the below error, IGPU Hanging I presume. my id is 9A49, I use my current working Installer EFI on the USB, only changed the values to disabled whatvergreen, enable nblue and removed device properties and the -igfxvesa boot flag.

Config.plist

Edited April 8 by Mastachief
Updated Boot with latest Nblue test

jalavoui · April 8

2024-03-16 00:35:59.879395+0000 localhost kernel[0]: (AppleIntelICLGraphics) [IGPU] virtual IOService *IntelAccelerator::probe(IOService *, SInt32 *): Found device with ID 0x9a498086, revision 0x1, PCH id 0x0, PCH rev 0x0 at PCI 0:2:0

previous release changed this values

this release change pch id but i'm unsure how ventura uses this

Mastachief

your log looks like typical hang when loading scheduler 4 or 5

the default atm is 3 so idk what is causing the hang

unless you have same display as me and this config breaks it (i doubt)

image.png.22f7b73289dd7031a757519b12282ff7.png

just in case i'm gonna add extra 999 so i dont break any1 lcd

'im trying to figure out what's wrong with memory allocations

2024-03-15 23:43:27.505574+0000 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][DISPLAY ] Value read from Mailbox for MEM_SS_INFO = 0x120\ 2024-03-15 23:43:27.505578+0000 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][DISPLAY ] RAM = 0x0\

some logs get it almost right

is this a bios setting ?

i added code to change Stolen Memory Size but the driver uses pciconfigreads to get some other values

this code will eventually work...

it's based on whatevergreen and ofc will be needed for some tweaks

frame->fUnifiedMemorySize = 3*1024*1024;
frame->fStolenMemorySize=	NBlue::callback->stolen_size;

Edited April 10 by jalavoui

Mastachief · April 9

This is my display info exported using hackintool, reason im looking at my edid is to see if its missing some properties needed.

edid.bin

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>DisplayProductID</key>
	<integer>1815</integer>
	<key>DisplayProductName</key>
	<string>Unknown Display</string>
	<key>DisplayVendorID</key>
	<integer>1970170734</integer>
</dict>
</plist>

Should i update nblue's info.plist using these values, or should i try to set it to be spoofed to a macbookair in hackintool first?

Also if im editing that info, should i edit the values in the display Apple ID Injection Array (More Likely) or theIOProviderMergeProperties (Less Likely)

image.png.e6c1f8d48b2bd457918886cf79ff1b85.png

I was hoping it wasnt my edid that was causing an issue so i regenerated it using the fixedid tool, i got the below exported

<key>IOKitPersonalities</key>
	<dict>
		<key>Monitor Apple ID Injection</key>
		<dict>
			<key>CFBundleIdentifier</key>
			<string>com.AnV.Software.driver.AppleMonitor</string>
			<key>DisplayProductID</key>
			<integer>1815</integer>
			<key>DisplayVendorID</key>
			<integer>1970170734</integer>
			<key>IOClass</key>
			<string>DisplayMergeNub</string>
			<key>IODisplayPrefsKey</key>
			<string>IOService:/AppleACPIPlatformExpert/PC00@0/AppleACPIPCI/IGPU@2/.Display_boot/display0/AppleDisplay-756e6b6e-717</string>
			<key>IOProviderClass</key>
			<string>AppleDisplay</string>
			<key>IOProviderMergeProperties</key>
			<dict>
				<key>DisplayProductID</key>
				<integer>40980</integer>
				<key>DisplayVendorID</key>
				<integer>1552</integer>
				<key>IOClass</key>
				<string>AppleDisplay</string>
				<key>IODisplayConnectFlags</key>
				<data>
				AAgAAA==
				</data>
				<key>IODisplayEDID</key>
				<data>
				AP///////wAGEBSgAAAAAAoWAQSlHRJ4Am+xp1VMniUM
				UFQAAAABAQEBAQEBAQEBAQEBAQEBLjaAoHA4H0AwIDUA
				WMIQAAAaHySAoHA4H0AwIDUAWMIQAAAaAAAA/ABDb2xv
				ciBMQ0QKICAgAAAA/QA4TB5TEQAKICAgICAgADIAAAAA
				AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
				AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
				AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
				AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
				</data>
				<key>IODisplayGUID</key>
				<integer>436849163854938112</integer>
				<key>IODisplayPrefsKey</key>
				<string>IOService:/AppleACPIPlatformExpert/PC00@0/AppleACPIPCI/IGPU@2/.Display_boot/display0/AppleDisplay-610-a014</string>
			</dict>
			<key>IgnoreDisplayPrefs</key>
			<true/>
		</dict>
	</dict>

Also this was made from my settings in the image below

image.png.742055e742e5d4e341aa4a982f2cd31a.png

Edited April 9 by Mastachief
Added pics, added edid

jalavoui · April 9

just disable it. you need to figure out why the driver fails. maybe try get syslog from hacintool

i updated code with (base code is in whatevergreen - this is just the property added to info.plist)

and no more screen flick at boot

image.png.75fcde6d7c921ebd4033cbd156f833bc.png

question: does any1 knows other hidden properties that can help us ?

for logs i use this in terminal

log show --style syslog --predicate 'processID == 0' --last 1h --info --debug > x.log

i've posted some log samples few posts ago

they dont need any special flags

Edited April 9 by jalavoui

benmacfreak · April 9

as i said i have NO idea how to do majority of what you guys are doing. all I know how to do is copy and replace kexts and try them. Beyond that, i'm clueless tbh.

Mastachief · April 9

I will do a change of my EFI folder for the USB, and add opencore debug, ill upload that log by tomorrow, the log was generated, but then its not show the debug lines,

@jalavoui Whats the Debug NVRAM flag for nblue?

shl628 · April 10

@Mastachief You can check it in the kern_start.cpp source file.

static const char *bootargDebug = "-NBlueDebug";

@jalavoui When I booted using the most recent NootedBlue.kext, it stopped at the photo below.

- WhenverGreen : Disabled
- IGPU Device Properties : do not inject
- boot-args : -v keepsyms=1 debug=0x100 -NBlueDebug
- macOS Version : macOS 13.6.5(22G621)

So, I edited the log output section for the patch in NootedBlue's source code using Xcode, built it, applied it, and then rebooted, and a log like the picture below was output.

Logs for the kextG11FB patch were output, but no logs were output to determine whether the 7 patches (f2, f2b, f3, f3a, f3b, f4, f4b) for kextG11HW were applied correctly or not.

image.png.aa1b0e84faa30c7255610d6ff0e833ae.png

Of course, before modifying NootedBlue's source code, I tried booting with PANIC_COND instead of SYSLOG_COND, but the kernel panic log did not appear on the screen and it just stopped.

In kern_gen11.cpp, are the f1, r1 patches of kextG11FB patches to bypass Unsupported CD Clock Frequency kernel panic?

//writeReg32(SOUTH_DSPCLK_GATE_D,PCH_GMBUSUNIT_CLOCK_GATE_DISABLE); Wa_14011294188:ehl,jsl,tgl,rkl,adl-s
static const uint8_t f1[] = {0x74, 0x28, 0x48, 0xFF, 0x05, 0x9E, 0x65, 0x0B, 0x00, 0xBE, 0x20, 0x20, 0x0C, 0x00, 0x4C, 0x89, 0xEF, 0xE8, 0x3F, 0xE2, 0xFF, 0xFF, 0x0D, 0x00, 0x10, 0x00, 0x00};
static const uint8_t r1[] = {0x90, 0x90, 0x48, 0xFF, 0x05, 0x9E, 0x65, 0x0B, 0x00, 0xBE, 0x20, 0x20, 0x0C, 0x00, 0x4C, 0x89, 0xEF, 0xE8, 0x3F, 0xE2, 0xFF, 0xFF, 0xb8, 0x00, 0x00, 0x00, 0x80};

Edited April 10 by shl628

jalavoui · April 10

try latest kext i've updated on last post

those bugs are from old code

the patch f1 is from linux

i'd like to get rid of apple connectors table and overwrite it with correct info kinda like linux

Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.183933] i915 0000:00:02.0: [drm:parse_ddi_port [i915]] Port A VBT info: CRT:0 DVI:0 HDMI:0 DP:1 eDP:1 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184016] i915 0000:00:02.0: [drm:parse_ddi_port [i915]] Port A VBT HDMI level shift: 0
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184094] i915 0000:00:02.0: [drm:parse_ddi_port [i915]] Port A VBT DP max link rate: 0
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184178] i915 0000:00:02.0: [drm:parse_ddi_port [i915]] Port B VBT info: CRT:0 DVI:1 HDMI:1 DP:0 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184263] i915 0000:00:02.0: [drm:parse_ddi_port [i915]] Port B VBT HDMI level shift: 0
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184340] i915 0000:00:02.0: [drm:parse_ddi_port [i915]] Port B VBT DP max link rate: 0
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184415] i915 0000:00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting DC state from 00 to 00
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184551] i915 0000:00:02.0: [drm:icl_verify_procmon_ref_values [i915]] Combo PHY A Voltage/Process Info : 0.85V dot0 (low-voltage)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184695] i915 0000:00:02.0: [drm:icl_verify_procmon_ref_values [i915]] Combo PHY B Voltage/Process Info : 0.85V dot0 (low-voltage)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184816] i915 0000:00:02.0: [drm:icl_display_core_init [i915]] enabling power well 1
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.184917] i915 0000:00:02.0: [drm:gen9_dbuf_slices_update [i915]] Updating dbuf slices to 0x3
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185033] i915 0000:00:02.0: [drm:__intel_display_power_get_domain.part.0 [i915]] enabling always-on
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185122] i915 0000:00:02.0: [drm:__intel_display_power_get_domain.part.0 [i915]] enabling DC off
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185211] i915 0000:00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting DC state from 00 to 00
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185315] i915 0000:00:02.0: [drm:icl_verify_procmon_ref_values [i915]] Combo PHY A Voltage/Process Info : 0.85V dot0 (low-voltage)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185436] i915 0000:00:02.0: [drm:icl_verify_procmon_ref_values [i915]] Combo PHY B Voltage/Process Info : 0.85V dot0 (low-voltage)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185535] i915 0000:00:02.0: [drm:__intel_display_power_get_domain.part.0 [i915]] enabling power well 2
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185627] i915 0000:00:02.0: [drm:__intel_display_power_get_domain.part.0 [i915]] enabling power well 3
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185718] i915 0000:00:02.0: [drm:__intel_display_power_get_domain.part.0 [i915]] enabling power well 4
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185803] i915 0000:00:02.0: [drm:__intel_display_power_get_domain.part.0 [i915]] enabling power well 5
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.185906] i915 0000:00:02.0: [drm:tgl_tc_cold_request [i915]] TC cold unblock succeeded
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.186001] i915 0000:00:02.0: [drm:intel_dmc_ucode_init [i915]] Loading i915/tgl_dmc_ver2_12.bin
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.186392] i915 0000:00:02.0: [drm:intel_fbc_init [i915]] Sanitized enable_fbc value: 1
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.186809] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM0 latency 3 (3.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.186950] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM1 latency 54 (54.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187081] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM2 latency 54 (54.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187223] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187192] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM3 latency 54 (54.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187273] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM4 latency 54 (54.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187334] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM5 latency 73 (73.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187401] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM6 latency 110 (110.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.187460] i915 0000:00:02.0: [drm:intel_print_wm_latency [i915]] Gen9 Plane WM7 latency 115 (115.0 usec)
Apr  7 21:21:13 linuxlite-iMacPro1-1 kernel: [   19.188282] i915 0000:00:02.0: [drm:intel_modeset_init_nogem [i915]] 4 display pipes available.

so much easier todo on amd

Edited April 10 by jalavoui

shl628 · April 10

On 4/7/2024 at 7:44 AM, jalavoui said:

this is intel way of assign metal family (rip amd)

atm nblue doesnt have framebuffer injection properties like busid, etc

but the info.plist allows changing a few properties

i'll try add a section to allow changing framebuffer properties kinda like whatevergreen

this are the base values

altough no acceleration and wrong connectors this release is fine

need others to change it for non working displays

current boot flag: -v

NootedBlue.kext.zip 20.7 kB · 3 downloads NootedBlue-master.zip 321.1 kB · 2 downloads

Are you referring to the recent post above?

I used NootedBlue.kext from the post above.

jalavoui · April 10

yes. idk why not working for you

keep the PANIC_COND it helps if patches fail to aplly on old ventura versions

maybe lilu version issue ?

this is 1.6.7 i'm using

Lilu.kext.zip

latest patches stoped opengl crash in windoserver

framebuffer mode is very fast on this platform

Edited April 12 by jalavoui

shl628 · April 12

On 4/10/2024 at 11:56 PM, jalavoui said:

yes. idk why not working for you

keep the PANIC_COND it helps if patches fail to aplly on old ventura versions

maybe lilu version issue ?

this is 1.6.7 i'm using

latest patches stoped opengl crash in windoserver

framebuffer mode is very fast on this platform

I applied the most recently uploaded NootedBlue.kext and the Lilu.kext you attached and booted, and booting stopped as shown in the picture below.

- WhenverGreen : Disabled
- IGPU Device Properties : do not inject
- boot-args : -v keepsyms=1 debug=0x100
- macOS Version : macOS Ventura 13.6.5 (22G621)

Edited April 12 by shl628

jalavoui · April 12

from your whatevergreen logs maybe you need something else

try add this patch to your custom whatevergreen version

// AppleIntelFramebufferController::hwSetMode skip hwRegsNeedUpdate

static const uint8_t f2[] = {0xE8, 0x31, 0xE5, 0xFF, 0xFF, 0x84, 0xC0, 0x74, 0x3D};

static const uint8_t r2[] = {0xE8, 0x31, 0xE5, 0xFF, 0xFF, 0x84, 0xC0, 0xEB, 0x3D};

show the boot log if it works

i just found that editing edid inside nblue info.plist brings back missing 60hz

guess more advanced settings can be done using this. hdpi ress seem to work

Capturadeecra2024-04-13as01_05_03.png.01e0c0022fcc47fc8435c550fdca0bfd.png

deleting this key makes nblue hang at boot

deleting its contents is fine

by default this does nothing. it's just a sample

to change get hackintool and replace the key after fix vendor/product

Capturadeecra2024-04-13as01_51_05.png.e1376986cbd30963aabdf8bd728fbd1e.png

Edited April 13 by jalavoui

benmacfreak · April 13

awesome work guys, i booted with ventura 13.6.6 on my laptop, it worked but i hadn't correct vram or opengl and metal. Nothing, idk why, i had the newest nblue linked and ilu 1.6.7 beyond that as i said before i dont know how else to fix it nor how to do kext edits and patching.

shl628 · April 13

@jalavoui Adding that binary patch to the WhateverGreen source code was a bit difficult for me, so I tried using the framebuffer-patchN-find/replace property instead.

image.png.971cbfb4a039c31aad354b29af3d1e98.png

It boots, but a black screen issue occurs.

After checking the log using the screen sharing function, it seems that WEG's framebuffer-patchN-find/replace patch property is not working well.

[   26.892387]: WhateverGreen      igfx: @ (DBG) patch 0 framebufferId 0x8A710000 failed
[   26.892401]: WhateverGreen      igfx: @ (DBG) patch 1 framebufferId 0x8A710000 failed
[   26.892415]: WhateverGreen      igfx: @ (DBG) patch 2 framebufferId 0x8A710000 failed

So, I opened the Framebuffer dump file (AppleIntelFramebuffer_15_22.6) I uploaded before with the HexFiend app and looked for the corresponding binary value.

framebuffer-patch0-find : not found

E831E5FF FF84C074 3D

So, I searched for E831E5FF FF84C0 and found one.
I checked and it is already set to E831E5FF FF84C0EB 3D.

image.png.e2a8e4cef5786584602d4febe987b170.png

framebuffer-patch1-find : found
E84E0D00 0085C075 40

image.png.140062b0c117bcd7e82c9c847bd06e7d.png

framebuffer-patch2-find : found
742848FF 059E650B 00BE2020 0C004C89 EFE83FE2 FFFF0D00 100000

image.png.dc42153055a079870ca2b2c348948caf.png

WEG Dmesg Logs.log

x.log.zip

Edited April 13 by shl628

jalavoui · April 13

yes this log show the patch is not applyed

2024-04-13 10:35:34.810026+0900 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][MODESET ] FB1:Path not active, needs full modeset for pipe 0
2024-04-13 10:35:34.810030+0900 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][MODESET ] Disable display called for without sw dc6 support
2024-04-13 10:35:34.810032+0900 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][DISPLAY ] FB1: Disabling Pipe A

this modd works for me but without igfxagdc enabled you get crash logs in /Library/Logs/DiagnosticReports

i noticed the ring bug seems fixed

i just copyed some of your settings

update

with -v igfxagdc=0 you get rid of crash bug

i'm happy its 1st time i make whatevergreen work for me

Edited 9 hours ago by jalavoui

shl628 · April 13

@jalavoui Thank you for editing the WhateverGreen source code.

When I applied WhateverGreen.kext you attached, booting was successful and the black screen problem was resolved. 🙂

jalavoui · April 13

cool. maybe upload to your github ?

found the cause of

2024-04-13 16:07:22.624399+0100 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][ERROR][GTPM_SLICESWITCH] : Invalid fRingTables, check if AGPM driver is loaded

it's related with choose ig-platform

with yours this doesnt happen

from logs i got some things to watch

the wrong port/index (maybe try wahtevergreen patch for a good combo)

the stolen memory size (that you fixed by changing in bios)

the dvmt max bios memory (mine is capped to 256m, maybe change to maxdvmt?)

and why this ?

-04-13 18:04:58.148412+0100 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][DISPLAY ] Value read from Mailbox for MEM_SS_INFO = 0x120
2024-04-13 18:04:58.148417+0100 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][LOG ][DISPLAY ] RAM = 0x0

doesnt happen for all users. but idk howto fix this

Edited April 13 by jalavoui

shl628 · April 13

6 minutes ago, jalavoui said:

cool. maybe upload to your github ?

Yes, it's okay.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites