Leaderboard

UPDATE: Aggiornata EFI a OC 0.9.1, rollback a iMacPro1,1... inserito SSDT universale Ciao a tutti, non pago del mio hack principale, fieramente AMD, con un po' di risparmi mensili e vendite di materiale mio più vecchio Intel + nVidia mi sono preso mesi fa questa mainboard Z690, curioso di testare sempre CPU e chipset non ufficialmente supportati da macOS, anche se della "controparte" Intel, restando su DDR4 perché le latenze della DDR5 sono a mio avviso ancora troppo alte rispetto al prezzo di vendita per produrre miglioramenti di performance sensibili: ...amo ASRock per prestazioni / prezzo / compatibilità e così non ho cambiato squadra... senza spendere un pozzo di soldi infatti l'ho accoppiata con questa CPU i5 12600k che per me è il miglior acquisto qualità prezzo se si vuole comprare un Alder Lake oggi: CPU composta da 10 core divisi in 6 + HT "classici" di potenza + 4 di efficienza energetica, roba da lasciare indietro gli i9 di decima e undicesima generazione in multicore, stracciandoli proprio in single core, campo in cui primeggia pure su qualsiasi CPU AMD. Alder Lake è così perfetto per carichi di lavoro che contano molto sull'IPC. Come dissipatore ho voluto provare per la prima volta il liquido e così un mio amico mi ha venduto a un prezzone questo kit AIO, veramente notevole per dimensioni del radiatore: Come RAM ho messo 32 Gb DDR4 2667 MHz d'avanzo dalla vecchia build i9 9900k venduta (a cui ho affibbiato i 16Gb più debolucci che vedete montati sopra in figura). Dopo un primo test "sul banco" con alimentatore del ciufolo da 400W micro ATX e iGPU integrata in Winzozz per vedere se tutto era funzionante a dovere a livello hardware prendo lo Chassis e inizio l'assemblaggio: Pure la GPU è di "recupero" per ora, una AMD Radeon RX 460 da 4 Gb con dissipatore custom perché la sua ventola era ferma (presa come scheda secondaria a pochi soldi illo tempore quando avevo la nVidia 3070 sulla mia build AMD e non volevo abbandonare macOS). Spero si abbassino le 6600XT perché vorrei acquistarne una se mai scenderà sui 400/450 eur nei prossimi mesi. Il Crucial da 1 Tb è di passaggio perché lo sto solo testando, lo rimpiazzerò appena possibile con un adeguato drive nvme degno del bus pciex 5 di questa grande piccola mobo. Il case Corsair Carbide 270R è veramente spazioso, i 360mm di radiatore ci sguazzano. Messo anche la Thunderbolt 3 Gigabyte Titan Ridge che mi tenevo da parte per futuri test con hardware adeguato che spero di fare presto e la Broadcom Wifi ac senza la quale non avrei potuto navigare visto che le ethernet intel integrate in Monterey sono ancora estremamente problematiche. L'alimentatore è un Coolermaster da 600W più che sufficiente ad ora. Ho cambiato opportunamente l'EFI che avevo per l'i9 9900k e la Z390 mantenendo l'installazione di Monterey 12.3 che avevo, fatto un po' di bench ed ho ottenuto questa meraviglia: ...CPU solamente a 60 gradi sotto massimo sforzo, sui 20 gradi in idle, risultato degno degli ultimi Mac Studio: Direi che il sistema di raffreddamento fa il suo sporco dovere egregiamente, e la CPU è sfruttata come si deve grazie al team di OpenCore. Eppure eppure... son convinto che se si applicassero così anche con le CPU AMD Zen, CPU non supportate tanto quanto le Intel Alder Lake ma da loro di fatto trascurate, avremmo un altro campione in macOS... ma evitiamo le polemiche e affianchiamo questo "muletto" Intel alla mia build ammiraglia. Come dico sempre, think REALLY different 😉 P.s.: ho lasciato la EFI con tutte le porte USB attive, appena possibile le mapperò nel dettaglio. Grazie per la pazienza!!! EFI 0.8.0 Alder i5 Asrock Z690.zip EFI 0.8.4 MacPro71.zip

🙂

*RISOLTO* Il piccolo OT Esatto ed è cosi, tra i vari tentativi con BrcmPatchRAM ho provato qualcosa di fisico: Invertire il collegamento degli Header USB sulla MOBO ed il risultato è stato positivo, funziona tutto perfettamente su mATX in firma con questa scheda (senza alcun Kext ovviamente). Il perché ad un profano come me è tuttora sconosciuto. Tra le due la Fenvi è quella che mi ha dato più soddisfazione, OOB su ATX in firma senza alcun piccolo intoppo sin dall'inizio (ovviamente anche questa senza alcun Kext essendo il chipset supportato nativamente), non riesco a caricare screenshot perché sono da mATX. Perdonate la mia piccola parentesi, in conclusione se dovessi consigliare una tra le due testate mi sbilancerei come su consiglio di @Ramirez71 sulla Fenvi T919, non perché l'altra non funzioni ma perché come detto sopra, mi ha dato un feedback migliore. Installati driver i su WIN11 e funziona perfetta senza alcun problema anche sul so Microsoft.

Fai partire l'installazione di win...nella scheda madre BIOS gli nvme vengono visti in un altro meno..non nel menu degli ssd/hdd ...fai partire l'installazione e vedi se win te lo vede!

Il primo sempre lilu, poi le sue plugin, per rispettare le dipendenze, infine tutto il resto senza un particolare ordine richiesto.

questo e l'ordine dei kext su tutti e due i sistemi in uso.

accade a seconda dei flag che hai qui lo segnalammo in passato con @antuneddue il dev ha risolto al volo Ora a seconda di cosa gli dai in pasto come config, aggiorna solo le voci in uso

Note: There are at least two known variants of this method, https://github.com/Carnations-Botanica/IntelMKLFixup and https://github.com/JonathanFerraz/FriendlyAMD please remember to quote and/or write in this thread for discussing and talking with us about forking and developing this methodology. Work must be respected! Some History, facts and strategy Certain Mac apps use the infamous Intel MKL libraries, now called Intel OneAPI: those libraries are x86_64 compliant but in the macOS porting certain functions are intended to work only on genuine intel cpus: these are __intel_fast_memset.A and __intel_fast_memcpy.A. We can fool these libraries redirecting their calls to __intel_fast_memset.J and __intel_fast_memcpy.J which both work perfectly on AMD Hackintoshes, and as fast as possible given the fact that we lack AVX512. But we also need to fool them changing the function __mkl_serv_intel_cpu_true returning TRUE even when running on AMD cpus!!! This fix is based on Daniel de Kok's hint on his brilliant article https://danieldk.eu/Posts/2020-08-31-MKL-Zen.html given that the old trick of setting the environmental variable MKL_DEBUG_CPU_TYPE to 5 has been deprecated by Intel for obvious reasons on rather recent MKL libs implementations. Using only these three "patches" we can virtually make every Intel only app run on our AMD Hacks natively without using hypervisors and without bypassing or deleting important functions / files of our specific app. I'm trying to write a tutorial to make everybody who has a very minimal knowledge of x86_64 assembly and machine language code able to patch any offending binary for AMD cpus. The goal is trying to keep bare metal execution of macOS instead of circumventing any issue using macOS virtualization, which I think is more complex and can be used profitevoly only in high end configurations (16 cores or more, 64 gigs of ram or more). With modern kernel patches the execution of the mach vanilla kernel is virtually perfect, not losing any kind of GPU performance: https://github.com/AMD-OSX/AMD_Vanilla. The procedure in detail To start searching for the correct hex patterns we can use two really useful programs: one is Hexfiend (I use version 2.14.1), an Hex Editor for macOS, which is totally free, and the other one is Hopper (I use version 5.3.1-demo), a disassembler, which is not free but is sufficient for us to "look into" suspect binaries in the search of those three procedures in the demo version, which is free for 30 minutes. So fire up Hopper and click Try the demo: Drag and drop a "suspect" binary, like libtbb.dylib, found in numerous app like Autodesk Autocad 2022 and Maya 2022: Leave all the default options on, be sure to keep Mach-O 64bits as Loader selected (here you could select other type of architectures if found in the binary). Configure the preferences according to this screen: Now wait for some time to let Hopper disassemble all the binary (some minutes for the biggest ones), write to the top left side of the main windows the word "Intel", select Proc. next to the box you've just written and you should get this screen: Focus your attention to the list of the procedures in the left part of the window: you can clearly see __intel_fast_memcpy.A and __intel_fast_memset.A in this binary. Let's click on the first procedure: The first number of this part of the window is 0x000000000035350: it is the Offset (your position in the binary), the second, 56, is the Machine Language translation of its mnemonic Assembly command push rsi: it uses only one byte of memory... after the ; you can read a human readable comment. The second line, 0x000000000035351, one exact byte later, has 5 bytes of code: E8 6A 00 00 00, and it means call (E8) the procedure which starts 00 00 00 6A bytes ahead (byte's order of data is reversed in x86 machine language and the Assembly call function needs four signed bytes after it, positive for a jump ahead, negative for a jump backwards) which is __intel_fast_memcpy, confirmed by the comment. We need to change this line of code to call __intel_fast_memcpy.J, which starts 0A (ten in decimal) bytes ahead so that it will become: 0x000000000035351 E80A000000 call __intel_fast_memcpy.J ; ... You can easily verify that at the end the __intel_fast_memcpy.J calls the AMD compatible procedure ___intel_new_memcpy. Using a familiar approach with Clover / OC Kernel patches (excluding bit masks) we can say: Find: 56 E8 6A 00 00 00 59 C3 Replace: 56 E8 0A 00 00 00 59 C3 We can easily do this using Hexfiend, open it and drag your binary into its main window, go to the program's menu and select Edit -> Find -> Find..., choose hex, put Find values in the top write field, Replace values in the second one, hit Next and the found pattern should be highlighted, finally hit Replace: Note: only one instance of the Find pattern must be found and replaced. Save the patched binary (on the desktop for example for now), let's double check our work opening it with Hopper and clicking on the __intel_fast_memcpy.A procedure: Yes, the line 0x000000000035351 appears exactly as we wanted! Good work... If something looks different, try again following the instructions from the beginning of this tutorial or ask for further explanations in this thread: Next, we can go on patching the __intel_fast_memset.A procedure. Same kind of work, click on this procedure in Hopper and inpect the code: ...let's focus our attention to its code: ...similarly to the latest patching procedure we need to change the second line (offset 0x000000000035481) to: 0x000000000035481 E80A000000 call __intel_fast_memset.J ; ... ...in Find / Replace terms: Find: 56 E8 4A 00 00 00 59 C3 Replace: 56 E8 0A 00 00 00 59 C3 Use Hexfiend exactly as before remembering only to replace one instance of the found hex pattern, save the binary to the desktop, open it with Hopper, select the __intel_fast_memset.A procedure and double check the resulting patched code with Hopper: Great! Even this time the AMD compatible J revision is called correctly as expected with our simple patch, and this revision finally calls the AMD friendly ___intel_new_memset procedure. Overwrite the original unpatched binary with yours on the desktop, then don't forget to recodesign it with this terminal command: sudo codesign --force --deep --sign - /path/to/the/binary/file.ext Note: using the offsets to find the hex patterns is not always a good idea because the way Hopper and Hexfiend calculate them could be different and with the demo version of Hopper we cannot directly write changes to files. Now we must explain how to patch the __mkl_serv_intel_cpu_true procedure, let's try with the krisp binary: open it with Hopper. If Hopper finds a FAT binary select 64 bit Intel Architecture and then always Mach-O 64 bit structure. Always write Intel on the procedure searching box then wait for Hopper to stop decompiling everything... finally click on the __mkl_serv_intel_cpu_true string: ...switch to the "recompiled" c view in Hopper and we can see that this procedure does a specific series of tests on the CPU registers to find out if you're running your code on an authentic Intel processor. Focusing on the Machine language code, the original procedure is 53 48 83 EC 20 8B 35 19 CC 67 04... and so on (85 F6 7C 08...): _mkl_serv_intel_cpu_true: 0x0000000100256440 53 push rbx ; ... 0x0000000100256441 4883EC20 sub rsp, 0x20 0x0000000100256445 8B3519CC6704 mov esi, dword [_cached.601.0.6] ; ... 0x000000010025644b 85F6 test esi, esi 0x000000010025644d 7C08 jl loc_100256457 loc_10025644f: 0x000000010025644f 89F0 mov eax, esi ; ... 0x0000000100256451 4883C420 add rsp, 0x20 0x0000000100256455 5B pop rbx 0x0000000100256456 C3 ret ; endp What can we use as a replace? We can easily cheat creating a function which always returns true without any register testing at all and replacing the original one, so as you can see using Hopper this Assembly code (which is in x86 Machine Language 55 48 89 E5 B8 01 00 00 00 5D C3) _mkl_serv_intel_cpu_true: 0x0000000100219580 55 push rbp ; ... 0x0000000100219581 4889E5 mov rbp, rsp 0x0000000100219584 B801000000 mov eax, 0x1 0x0000000100219589 5D pop rbp 0x000000010021958a C3 ret ; endp ...is the same than this trivial C code program: function _mkl_serv_intel_cpu_true { return 0x1; } What if we do this Find / Replace? Find: 53 48 83 EC 20 8B 35 19 CC 67 04 Replace: 55 48 89 E5 B8 01 00 00 00 5D C3 Just like with the other two patched procedures above, open Hopper and drag your binary into its main window, go to the program's menu and select Edit -> Find -> Find..., choose hex, put Find values in the top write field, Replace values in the second one, hit Next and the found pattern should be highlighted, finally hit Replace... again make sure to do this only once and double check the results with Hopper opening the patched binary, the __mkl_serv_intel_cpu_true needs to appear as in this picture: Note that we can stop at 11 bytes in the find pattern since the replace ends with C3 which is a RET Assembly instruction: take it as "a kind of an END", so even if the original procedure was longer when we call the patched one the code beyond the 11 patched bytes won't be executed, ever! Always remember to overwrite the unpatched binary and recodesign the patched binary: sudo codesign --force --deep --sign - /path/to/the/binary/file.ext The final result is that even with an AMD CPU our patched Intel testing procedure always returns TRUE, fooling the binary that it is running on a Genuine Intel processor. Combining this with the two above patches virtually any problematic app for our AMD Hackintosh can be run without crashes, without deleting program functionalities, but only modifying what is needed, not any byte more, even with SIP enabled. How can I find which binaries do I need to patch? The crash log of our problematics apps are very useful to get a list of libraries to get patched: the info you get from the crashed thread is crucial. For example, if we try to run the latest Krisp we can get this crash log: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: krisp [56056] Path: /Applications/krisp.app/Contents/MacOS/krisp Identifier: ai.krisp.krispMac Version: 1.32.16 (1.32.16) Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2022-02-19 12:53:40.1955 +0100 OS Version: macOS 12.2.1 (21D62) Report Version: 12 Anonymous UUID: 904323A8-BF9D-B98D-DD83-B25231CAC583 Time Awake Since Boot: 480000 seconds System Integrity Protection: disabled Crashed Thread: 0 Dispatch queue: ai.krisp.vp Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00007ff7b9356ff8 Exception Codes: 0x0000000000000002, 0x00007ff7b9356ff8 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [56056] VM Region Info: 0x7ff7b9356ff8 is in 0x7ff7b5b57000-0x7ff7b9357000; bytes after start: 58720248 bytes before end: 7 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_MEDIUM (reserved) 7f9e1f800000-7f9e20000000 [ 8192K] rw-/rwx SM=NUL ...(unallocated) GAP OF 0x5995b57000 BYTES ---> STACK GUARD 7ff7b5b57000-7ff7b9357000 [ 56.0M] ---/rwx SM=NUL ... for thread 0 Stack 7ff7b9357000-7ff7b9b57000 [ 8192K] rw-/rwx SM=PRV thread 0 Thread 0 Crashed:: Dispatch queue: ai.krisp.vp 0 libtbbmalloc.dylib 0x10bdd22d1 _intel_fast_memset.A + 1 1 libtbbmalloc.dylib 0x10bdd22d6 _intel_fast_memset.A + 6 Thread 1: 0 libsystem_pthread.dylib 0x7ff81dc66fec start_wqthread + 0 As you can see the offending binary, libtbbmalloc.dylib, can easily be detected by the crashed thread, which is Thread 0 in this case, and even the offending procedure can be deduced clearly: _intel_fast_memset.A If you patch only this lib and this procedure and try to run again Krisp you will find new infos in the new crash log, _intel_fast_memcpy.A in the same libtbbmalloc.dylib, then running again and analyzing the last crashlog libtbb.dylib with _infel_fast_memset.A and then _intel_fast_memcpy.A and so on, till the app running error free just like on Intel hackintoshes. It's a process of trial and error. Sometimes the app seems to work perfectly but triggering one or more specific functions in its menu makes it hanging or crashing... Generally in the crash logs take note of all the libraries loaded in all the threads, exclude the Apple System ones which are always compatible, focus on the third party ones... 70% of the time they are part of the MKL suite, 10% part of the Intel Threading / IO system, 10% third party ones (for example GenericMacIntel.dylib or AVXMacIntel.dylib in Waves) and sometimes the main app binary is also a possible candidate to be patched. You may also need to search the possible offending files in "/Library/Application Support/Appname" or "~/Library/Application Support/Appname" if you can't figure out them in the canonical Application folder. Which applications work with these patches? The list of apps I've found and verified totally working by now is in this thread (the list is growing): Can we generalize / automatize this method? If you follow my tutorial point by point for every binary you will find out the EXACT pattern to be searched and replaced for each procedure incompatible with AMD to be patched. But during the patching of many possible binaries we can find out some variations in the Find hex pattern... for __mkl_serv_intel_cpu_true the most generic find is, besides being always 11 bytes long: Find: 53 48 83 EC 20 8B 35 xx yy zz ww where xx yy zz ww are generic bytes, different one from another, and the replace is always: Replace: 55 48 89 E5 B8 01 00 00 00 5D C3 With __intel_fast_memset.A and __intel_fast_memcpy.A functions we need to expand the search pattern to avoid patching wrong regions of our binary: Find: xx xx xx xx 56 E8 yA 00 00 00 59 C3 where xx are 4 bytes all equal to 90 or FF and y is a nybble (half a byte) equal to 6, 5, 4 or 3 Replace: xx xx xx xx 56 E8 0A 00 00 00 59 C3 We should use perl to do searching and replacing using this syntax, taking as an example a Waves 12 specific plugin to be patched, but we cannot use find/replace masks, only direct searching: sudo perl -i -pe 's|\x90\x90\x90\x90\x56\xE8\x4A\x00\x00\x00\x59\xC3|\x90\x90\x90\x90\x56\xE8\x0A\x00\x00\x00\x59\xC3|sg' /Applications/Waves/Plug-Ins\ V12/ArtistDlls1.14_12.7/1196704578.bundle/Contents/MacOS/GenericMacIntel.dylib s|\x90\x90\x90\x90\x56\xE8\x4A\x00\x00\x00\x59\xC3 is the find string byte by byte |\x90\x90\x90\x90\x56\xE8\x0A\x00\x00\x00\x59\xC3 is the replace string byte by byte We could try to create a Lilu's plugin, or an EFI module, to intercept and patch such patterns in memory on the fly, but this goes beyond my skills. I'll leave this possibility open to the most advanced coders / developers here. I hope everything is crystal clear... remember to post here your comments / doubts / improvements / critics: Tomnic

Tante angurieeee ! Vedo che alziamo il livello ... qui