Mastachief Posted April 4 Share Posted 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? Link to comment Share on other sites More sharing options...
Slice Posted April 4 Share Posted April 4 22 minutes ago, Mastachief said: So I should use Fake SMC then? It is always good idea. Link to comment Share on other sites More sharing options...
jalavoui Posted April 5 Share Posted April 5 (edited) 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 Link to comment Share on other sites More sharing options...
benmacfreak Posted April 5 Share Posted 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? Link to comment Share on other sites More sharing options...
Mastachief Posted April 5 Share Posted 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. Link to comment Share on other sites More sharing options...
jalavoui Posted April 5 Share Posted April 5 (edited) 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 1 2 Link to comment Share on other sites More sharing options...
jalavoui Posted April 6 Share Posted April 6 (edited) 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 Edited May 1 by jalavoui 3 Link to comment Share on other sites More sharing options...
Mastachief Posted April 7 Share Posted April 7 (edited) 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 Link to comment Share on other sites More sharing options...
jalavoui Posted April 8 Share Posted April 8 (edited) 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) 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 1 Link to comment Share on other sites More sharing options...
Mastachief Posted April 9 Share Posted April 9 (edited) 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) 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 Edited April 9 by Mastachief Added pics, added edid Link to comment Share on other sites More sharing options...
jalavoui Posted April 9 Share Posted April 9 (edited) 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 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 1 Link to comment Share on other sites More sharing options...
benmacfreak Posted April 9 Share Posted 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. Link to comment Share on other sites More sharing options...
Mastachief Posted April 9 Share Posted 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? Link to comment Share on other sites More sharing options...
shl628 Posted April 10 Author Share Posted April 10 (edited) @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. 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 Link to comment Share on other sites More sharing options...
jalavoui Posted April 10 Share Posted April 10 (edited) 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 Link to comment Share on other sites More sharing options...
shl628 Posted April 10 Author Share Posted 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. Link to comment Share on other sites More sharing options...
jalavoui Posted April 10 Share Posted April 10 (edited) 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 Link to comment Share on other sites More sharing options...
shl628 Posted April 12 Author Share Posted April 12 (edited) 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 1 Link to comment Share on other sites More sharing options...
jalavoui Posted April 12 Share Posted April 12 (edited) 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 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 Edited April 13 by jalavoui Link to comment Share on other sites More sharing options...
benmacfreak Posted April 13 Share Posted 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. Link to comment Share on other sites More sharing options...
shl628 Posted April 13 Author Share Posted April 13 (edited) @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. 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. framebuffer-patch1-find : found E84E0D00 0085C075 40 framebuffer-patch2-find : found 742848FF 059E650B 00BE2020 0C004C89 EFE83FE2 FFFF0D00 100000 WEG Dmesg Logs.log x.log.zip Edited April 13 by shl628 Link to comment Share on other sites More sharing options...
jalavoui Posted April 13 Share Posted April 13 (edited) 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 May 5 by jalavoui 3 Link to comment Share on other sites More sharing options...
shl628 Posted April 13 Author Share Posted 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. 🙂 1 Link to comment Share on other sites More sharing options...
jalavoui Posted April 13 Share Posted April 13 (edited) 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 Link to comment Share on other sites More sharing options...
shl628 Posted April 13 Author Share Posted April 13 6 minutes ago, jalavoui said: cool. maybe upload to your github ? Yes, it's okay. Link to comment Share on other sites More sharing options...
Recommended Posts