All Activity

The question is "Will the Ventura be compatible with existing software and hardware configuration?".

Hellp, I give you some simple instructions to install ventura on mac: Go to the App Store by dragging the Apple menu down. Click on the Ventura information or use the search box on the left side of the App Store main page to find the app. You may begin downloading macOS Ventura from the official website by clicking the Get button. After the download is complete, the installer will launch without your intervention.

@jalavoui I am attempting to apply the additions and modifications to jalavoui's most recently uploaded NBlue source code to WhateverGreen. I added 5 RouteRequests for ICLLP Framebuffer, and added the code content and prototype definitions of 5 related methods to kern_igfx.cpp and kern_igfx.hpp. KernelPatcher::RouteRequest request("__ZN31AppleIntelFramebufferController15hwSetPanelPowerEj", hwSetPanelPower); patcher.routeMultiple(index, &request, 1, address, size); KernelPatcher::RouteRequest request2("__ZN21AppleIntelFramebuffer17prepareToExitWakeEv", prepareToExitWake); patcher.routeMultiple(index, &request2, 1, address, size); KernelPatcher::RouteRequest request3("__ZN21AppleIntelFramebuffer14disableDisplayEb", disableDisplay, odisableDisplay); patcher.routeMultiple(index, &request3, 1, address, size); KernelPatcher::RouteRequest request4("__ZN21AppleIntelFramebuffer18setPanelPowerStateEb", setPanelPowerState, osetPanelPowerState); patcher.routeMultiple(index, &request4, 1, address, size); KernelPatcher::RouteRequest request5("__ZN31AppleIntelFramebufferController10LightUpEDPEP21AppleIntelFramebufferP21AppleIntelDisplayPathPK29IODetailedTimingInformationV2", LightUpEDP, oLightUpEDP); patcher.routeMultiple(index, &request5, 1, address, size); However, a non-static related error occurs for data members whose names have an o in front of them. If I add the static keyword in front of mach_vm_address_t in kern_igfx.hpp, the error disappears, but is it okay to solve it this way? I'm attaching my modified WhateverGreen source code. WhateverGreen.zip

Since OC 0.9.7, duet doesn't work for me. Some of OC I builded myself, others I downloaded. I use duet in 4-5 legacy rigs. With some version it don't boot at all with an error message, others boot but after drive selection, black screen and back to OC picker (last OC has this behaviour). It is true that I don't used debug version and I don't compiled myself the last OC. Next week I'll investigate more and give feedback, since I'm not at home.

I think it requires registration. They speak about open source but no link to sources.

There's source code?

@Mona NurHave you thoroughly read and followed this guide and downloaded and tried the provided EFI? https://www.hackintosh-forum.de/forum/thread/59364-ryzentosh-mini-pc-amd-ryzen-7-5700u/ Edit: Here is the EFI folder: EFI for ACEMAGICIAN AM06 Mini PC, AMD Ryzen 7 5700U.zip

there's one detail 2024-04-25 23:41:40.982826+0100 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][INFO ][POWER ] FB0: power state transition Wake --> Doze 2024-04-25 23:41:40.982847+0100 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][INFO ][POWER ] FB0: Power state transition completed 2024-04-25 23:41:43.254170+0100 localhost kernel[0]: (AppleIntelICLLPGraphicsFramebuffer) [IGFB][INFO ][POWER ] FB0: power state transition Doze --> Wake i cant test this with a external usb disk but i think i got it did a fast test before entering true sleep and the display recovered if i allow a full sleep ofc it hangs cause i'm on a external usb not sure if this hacks still needed from hacintool NootedBlue.kext.zipNootedBlue-master.zip not much todo for oc i just add the whatevergrren flag (when i load it) opencore.zip btw this 3GB video memory is also a nblue patch for testing

Well, define “tried”, this is a multi-step fix that requires latest AUDK as well. OpenDuet should work just fine again, except for NOOPT, which is still being worked on.

Could you share your config.plist for the latest nblue?

So I tried it now (whether I did it right?? I have no idea) I already have Nootered on it. But unfortunately without success. Would you mind if you took a look at it? DSDT.aml

i just downgraded, wasnt worth the headache at all lol

I am using open source https://www.analogway.com/americas/products/software-tools/aw-edid-editor/ But there is almost nothing to edit. Two patches made by Clover is more than enough.

Use SSDTTime to create your own SSDT files from your systems DSDT, https://github.com/corpnewt/SSDTTime You might still need to use the precompiled ones for Nootered.

Do you have an idea that I can find out what is responsible for the WIFI? so I can incorporate this into my data?

From https://github.com/andyvand/FixEDID rebuild for ventura FixEDID-master.zipDebug.zip my fav code DisplayMergeNub::start(IOService *provider) { IOLog("%s\n", (const char *)DisplayMergeNubVersionString); IOLog("Version %f\n", DisplayMergeNubVersionNumber); IOLog("Copyright © 2013-2014 AnV Software\n"); return (true); }

this is the correct path for internal display, i mean it should always attach to framebuffer zero done by patching connectors order. you can copy con 1 to con 0 and zero all other values after con 0 this is the ready to patch source with a default custom igplatform injection. dont add device parameters if you wanna use it issue is with wrong parameters bus id, etc the lcd power call causes a kp so if you can find those values i think working power call will allow sleep/wake to work also with correct values maybe the interupts start to work and the acelerator fires up i recommend taking decompkernelcache and put the binary in ghidra for debugging and get correct bytes to patch this is "default" i'm using connectors patch come from DAT_000b0f9c (kern_gen11.cpp) _DAT_00163de0 = 0x8a5c0002; _DAT_00163de4 = 0; _DAT_00163de8 = "Intel Iris Plus Graphics"; DAT_00163df0 = 1; DAT_00163df1 = 3; DAT_00163df2 = 3; DAT_00163df3 = 3; _DAT_00163df4 = 0x4000000; _DAT_00163df8 = 0; _DAT_00163dfc = 0x60000000; func_0xffffffffeb5b90ea(&DAT_00163e00,&DAT_000b0f9c,0x90); _DAT_00163e90 = 0xe304; _DAT_00163e98 = 0; _DAT_00163ea0 = &gComboPhyDPTable; _DAT_00163ea8 = 0; _DAT_00163eb0 = &gComboPhyDPTable; _DAT_00163eb8 = 0; _DAT_00163ec0 = &gComboPhyHDMITable; _DAT_00163ec8 = 7; _DAT_00163ed0 = 3; _DAT_00163ed4 = 4; _DAT_00163ed8 = 270000000; _DAT_00163edc = 0; _DAT_00163ee0 = 0; _DAT_00163ee4 = 0; _DAT_00163ee8 = 2; _DAT_00163eec = 8; _DAT_00163ef0 = 6; DAT_00163ef4 = 0; _DAT_00163ef8 = 0x8a520002; _DAT_00163efc = 1; done in ventura 13.6.6 this offets exist in code like AppleIntelFramebufferController::hwSetPanelPower() but guess not for tiger lake family #define PCH_PP_STATUS _MMIO(0xc7200) #define PCH_PP_CONTROL _MMIO(0xc7204) #define PCH_PP_ON_DELAYS _MMIO(0xc7208) #define PCH_PP_OFF_DELAYS _MMIO(0xc720c) #define PCH_PP_DIVISOR _MMIO(0xc7210) unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt) { struct drm_i915_private *i915 = gvt->gt->i915; if (IS_BROADWELL(i915)) return D_BDW; else if (IS_SKYLAKE(i915)) return D_SKL; else if (IS_KABYLAKE(i915)) return D_KBL; else if (IS_BROXTON(i915)) return D_BXT; else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915)) return D_CFL; return 0; } well now i got why this displays can't work and a hack is need update: this panic is easy to avoid added 1 connector only for testing

I tried, same problem.

yes i am afraid so , it works, all boots, but the performance is terrible.

You are absolutely right. I know that G4s especially 8500T can be found for less than 100$ but the cheapest Mini with dGPU I have ever seen was 300$. Not that I need more computers to play with ... but it will be fun to see it working and be able to enjoy some games on low/medium 1080p.

I bought it from someone local, but you can find them cheap on Ebay. I've seen them for as low as $100 USD on Ebay (try searching for 'HP Mini EliteDesk 800 G4 65W 8th Gen i5-8500T' and inspect the listings). Sometimes sellers don't include the AMD graphics in the title/text (maybe because they don't even know what they're selling).

I am hopeful that the OC OpenDuet issues that I've experienced since OC 0.9.7 are resolved in the next release of OC. The fix "Fixed problem loading non-firmware runtime drivers" seems promising.

That's exciting! Looking forward to see the results. I was thinking of getting one of those but the price to performance didn't justify it enough for me. If not a super confidential information - where did you purchase the Mini from ?

Glad to See @Andy Vandijck and @spakk are still on the scene.