Contribute
Register

Z690 Chipset Motherboards and Alder Lake CPU

System restart in loop when I enable this quirk.
Any developer out there ? PatchProvideCurrentCpuInfo will execute this code :


The current code indeed bypasses x86_validate_topology. However, my theory without studying the code closely is that it also patches our CPU with some other info which I think messes up the comet lake spoofing ID so that’s why we get a boot loop with incompatible processor or something like that .

Hopefully can have time to compile this in debug mode to print out a few more info to see what this routine is doing exactly
 
Strange thing is, I noticed a massive delay using EFI3a when booting up, but not the new build I used from my Z490 Aorus Xtreme. Also my build doesn't contain a SSDT-RHUB which is expected in a typical Asus board.
OpenCore DEBUG is slower than the RELEASE version, but it provides more useful logs and can drop a SysReport, which is always useful to have. It was advised to switch to RELEASE once DEBUG has done its work…
In hindsight, it might have been better to distribute both a DEBUG EFI, to gather info, and a complete RELEASE EFI folder for the finishing touches and actual use rather than squeezing the two in one to save some space. But I did not expect that OS X would boot so quickly and so easily on Alder Lake!
 
That's the kind of news...!!

So I'm going to join the crew.
I get an ITX Z690 (sff addicted) with i5 12600KF
Only issue we haven't got many boards yet in Europe/Italy
I'm also in Italy and currently looking for a good place to get a DDR5 board for a 12900K without spending an arm and leg as happens 99% of the time in the EU zone with hardware, unfortunately.
 
I'm also in Italy and currently looking for a good place to get a DDR5 board for a 12900K without spending an arm and leg as happens 99% of the time in the EU zone with hardware, unfortunately.
It usually takes up a bit longer for the supply chain to get going...then prices come down, then people buy, then you find good deals on Amazon Warehouse...this takes months though.
t the moment, for example, there aren't even all the boards that were announced...
 
I'm actually surprised you were able to wait this long given all the excitement about the rate of developments here!!
I guess that @CaseySJ really does not need yet another hackintosh build and tried long to be reasonable and resist the itch… Well, we all are humans, aren't we?
There is good part to his pick of a Gigabyte Z690: On Z590 Gigabyte's implementation of Thunderbolt 4 is somewhat broken and does not allow (yet?) hot-plug with OS X, contrary to Asus' implementation. If this still applies to Z690, @CaseySJ may well fix it all and kill two birds with one stone.

Which brings the next point:
Thank you! If it's related, what's the best-reliable build I can purchase for my second Hackintosh right now? (Motherboard and CPU)? given that I will use my Radeon VII (Water-cooled with Kraken x73) so happy with this card. My needs are essentially the Thunderbolt, extra slots of PCI-E for some extra cards like decklink 4K etc..and finally M2 slots..
If this is a production machine, the choice right now for a reliable build with Thunderbolt is to go Z490 + 10th generation CPU: This is known to be reliable and Thunderbolt 3 is possible, including with Thunderbolt bus if needed. If many PCIe lanes are required, look for X299/C422 (48*PCIe 3.0… this is 9th generation).
Z590 is still somewhat rough and Thunderbolt hotplug if manufacturer-dependent, tough a flashed add-in card could be a solution. Z690 is fresh from this week and obviously fails the "reliable" criteria: It has been benchmarked but not yet "tested" in a meaningful way. I suspect that knowing how AVX works and whether Alder Lake suffers the same issues as Ryzen with Adobe (After Effects?), Da Vinci Resolve, etc. is of relevance to you.

If you can wait, say, until next year (and with more options from the "small die" Alder Lake without E-cores), then we may know whether Alder Lake can be recommended for a reliable build.
 
Any developer out there ? PatchProvideCurrentCpuInfo will execute this code :


The current code indeed bypasses x86_validate_topology. However, my theory without studying the code closely is that it also patches our cpu with some other info which I think messes up the comet lake spoofing ID so that’s why we get a boot loop with incompatible processor or something like that .

Hopefully can have time to compile this in debug mode to print out a few more info to see what this routine is doing exactly
Very nice find!
Reading the comments (I can't really do more) suggests it was devised for hypervisors and may not provide the required informations for running on bare metal.
 
I guess that @CaseySJ really does not need yet another hackintosh build and tried long to be reasonable and resist the itch… Well, we all are humans, aren't we?
There is good part to his pick of a Gigabyte Z690: On Z590 Gigabyte's implementation of Thunderbolt 4 is somewhat broken and does not allow (yet?) hot-plug with OS X, contrary to Asus' implementation. If this still applies to Z690, @CaseySJ may well fix it all and kill two birds with one stone.

Which brings the next point:

If this is a production machine, the choice right now for a reliable build with Thunderbolt is to go Z490 + 10th generation CPU: This is known to be reliable and Thunderbolt 3 is possible, including with Thunderbolt bus if needed. If many PCIe lanes are required, look for X299/C422 (48*PCIe 3.0… this is 9th generation).
Z590 is still somewhat rough and Thunderbolt hotplug if manufacturer-dependent, tough a flashed add-in card could be a solution. Z690 is fresh from this week and obviously fails the "reliable" criteria: It has been benchmarked but not yet "tested" in a meaningful way. I suspect that knowing how AVX works and whether Alder Lake suffers the same issues as Ryzen with Adobe (After Effects?), Da Vinci Resolve, etc. is of relevance to you.

If you can wait, say, until next year (and with more options from the "small die" Alder Lake without E-cores), then we may know whether Alder Lake can be recommended for a reliable build.
As far as you know, does Rocket Lake suffer from the same issues?

So does an i7 11700K in a Z590 board with SMBIOS MacPro7,1 suffer on Adobe app, Photoshop?

I'm asking as I have the system go into black screen when using Photoshop simply drawing a simple line.
Thanks
 
Last edited:
Thank you! Z690 Aorus Master has AQtion AQC113C. I hope AQC113C use the same kext like AQC113.
Here is AQC113 variants devices natively supported by Monterey 12.0.1 :
Capture d’écran 2021-11-12 à 09.18.19.png


VID 0x1D6A PID 0x00C0 seem to be an engineering sample model
VID 0x1D6A PID 0x04C0 seem to be AQC113 10Gbit model
VID 0x1D6A PID 0x94C0 seem to be AQC113CS 10Gbit model
VID 0x1D6A PID 0x93C0 seem to be AQC114CS 5Gbit model

If AQC113C model has a different device-id, we can patch it under Opencore/Device properties.

Attached Product brief, for now, these are Marvell products ... not movies :mrgreen:

Update 1: inverted PID & VID ..

Update 2: Unfortunally, AQC113C have a different PID 0x14C0 following this website, we should try patching device-id and make some performance tests
 

Attachments

  • marvell-fastLinq-edge-aqc113-aqc113c-aqc113cs-aqc114cs-aqc115c-aqc116c-product-brief.pdf
    106.8 KB · Views: 381
Last edited:
Have a look at this under Fixing IGPUs. There is a fix for Ice Lake+ IGPUs that could help called -noDC9 > https://dortania.github.io/OpenCore-Post-Install/universal/sleep.html#fixing-gpus

If the screen panics you should also check the IGPU device-id. I don't recommend spoofing Coffee Lake IGPU & CPU for Alder Lake. Use Comet Lake values instead 00009BC5 for AAPL,ig-platform-id, 9BC50000 for device-id & SMBIOS of iMac20,1.
iGPU is witched off. It's an i7 11700K my bad sorry, I wrote 10700K !!
 
As far as you know does Rocket Lake suffer from the same issues?
So does an i7 10700K in a Z590 board with SMBIOS MacPro7,1 suffer on Adobe app, Photoshop?
I'm asking as I have the system go into black screen when using Photoshop simply drawing a simple line.
Thanks
As far as I understand, the issue is that OS X software probes for CPU capability by checking SMBIOS.
MacPro7,1 and iMacPro1,1 promise AVX-512. Rocket Lake has AVX-512 and is fine. Comet Lake and earlier do not have AVX-512; so calling optimised AVX-512 code on a Comet Lake build with MacPro7,1 SMBIOS causes a crash. iMac SMBIOS promise only AVX-2, so with a proper iMac SMBIOS for your Comet Lake build, Photoshop would not load its AVX-512 code and run fine.

AVX situation on Alder Lake is… complicated. Intel only guarantees AVX-2, because that's how far the E-cores go, and has written so in the technical documentation. But the P-cores actually have AVX-512 units, which may or may not be validated when testing the die, and some BIOS implementations (apparently not all), allow to activate AVX-512 when E-cores are off.
How this plays off and whether it works is to yet to be tested.
With a caveat: Prior to launch, it was said that AVX-512 units in P-cores were present but fused off. This is not the case in the first batch of Alder Lake CPUs, but Intel could change course and actually fuse off AVX-512 in further steppings.
 
Back
Top