dreamwhite

Hahaha benissimo. Grazie mille del chiarimento ^^

Grazie mille per il chiarimento ^^ A questo punto però mi sorge spontaneo un dubbio: mettiamo caso che l'utente autore del topic in questione decida di fare un dual boot win/mac o linux/mac e avvia il sistema operativo tramite OpenCore (e che quindi inietta l'ssdt per la mappatura delle USB). Quando il sistema sarà avviato, Linux o Windows rienumereranno (godzilla had a stroke trying to write this and died) le porte USB oppure considereranno solo le porte USB definite nell'SSDT?

Alright, vedrò se l'utente sarà interessato a "sacrificare" 3 porte USB e nel caso procediamo alla disattivazione delle relative porte USB. Domanda: in termini di stabiiltà del sistema, con e senza XhciPortLimit, vi è qualche differenza? Magari mi sbaglio, ma in generale il termine patch, mi fa pensare in automatico a qualche problema che potrebbe derivarne. Saresti così gentile da chiarirmi questo stupido dubbio? Ciao e grazie

Buongiorno a tutti (mi ero dimenticato di farlo nella risposta precedente haha). Dunque, per quanto riguarda la scelta di abilitare 18 porte, mi sono basato principalmente sul fatto che la scheda madre dell'utente, una AsRock Z490M Pro 4, ha queste porte USB nel back-panel: Dunque, partendo da sx verso dx contiamo: 4 porte USB-A logiche (2x 3.0 e 2x 2.0 retrocompatibili) 2 porte USB-A logiche (1x 3.0 e 1x 2.0 retrocompatibile) 2 porte USB-C logiche (1x 3.0 e 1x 2.0 retrocompatibile) 4 porte USB-A logiche (2x 3.0 e 2x 2.0 retrocompatibili) totale porte: 12 porte USB Ora, fatta questa considerazione, bisogna includere nella mappatura anche la porta USB dell'header interno a cui è collegata la Fenvi T919 che, stando a quanto ricordi è identificata in HS13, e le porte USB presenti sul front-panel del suo case. Rieffettuando il calcolo (ossia considerando 2 porte logiche per ogni porta USB 3.1 gen 1) si arriva alla fatidica cifra di 18 porte USB totale, che richiedono per tanto l'attivazione del quirk XhciPortLimit. Sia chiaro, è pur sempre possibile ridurre il numero di porte USB a quelle strettamente necessarie, ma ho preferito (magari sbagliando, non so) attivare tutte le porte USB possibili 😕 Se c'è da rieffettuare la mappatura delle porte USB non c'è alcun problema. Sia @Gengik84 , così come altri staffer di macos86.it, così come tanti altri, sanno come funziona il metodo GENG e per tanto non è un problema disattivare eventuali porte 🙂 Resto in attesa di vostre ^^ dreamwhite

Dovrei rivedermi meglio SSDT-Basic, ammetto, ma in ogni caso, non penso che sia SSDT-Basic a fare la differenza con lo sleep dal momento che il problema è relativo a questa periferica CNVW 😕 Ma magari mi sbaglio My bad, In ogni caso basta verificare il metodo _STA delle due periferiche e far si che sia attivo solo RTC, dal momento che macOS è compatibile solo con quello. A giudicare dalle sue ACPI (e dal fatto che boota anche), SSDT-AWAC è corretto. Allego foto dei metodi _STA di AWAC e RTC provenienti dal DSDT dell'utente: DEVICE AWAC DEVICE RTC Per far si che RTC sia attivo e utilizzabile da macOS occorre dunque impostare la variabile STAS su One. Ergo, va bene SSDT-AWAC presente nella sua EFI. Se ci sono correzioni da apportare, sono più che curioso di testarle, purchè siano in grado di risolvere il problema dello sleep wake. Ne stiamo uscendo pazzi 😢 Grazie a tutti per il contributo dreamwhite

Al momento non sono al PC e non credo di accenderlo prima di domattina. Banalmente le porte disattive sono quelle il cui metodo _UPC ritorna "GUPC (Zero)". Domani ti elenco quali sono le porte e analizziamo insieme il problema 🙂 Buonanotte

Buonasera e perdonami l'intrusione. Ho seguito personalmente l'utente in questione e non vedo motivo di dire "non hai disabilitato neanche una porta USB". Dal momento che nella sua tabella ACPI relativa alle USB (per l'appunto SSDT-3-xh_cmsd4) è definito il metodo GUPC, questi consente la disattivazione della porta impostando Arg0 su "Zero". Secondo l’Advanced Configuration and Power Interface (ACPI) Specification, version 6.3, pagina 673, il metodo _UPC ha come valore di ritorno il seguente Package: Return Value Information: Package { Connectable // Integer (BYTE) Type // Integer (BYTE) Reserved0 // Integer Reserved1 // Integer) } Se la matematica non è un'opinione e gli array partono da 0, impostando il primo elemento dell'array (di indice 0, per l'appunto), su Zero, il parametro Connectable, di tipo Integer, disattiva la porta, ergo non è necessario utilizzare il metodo GENG per la disattivazione della porta. Sia chiaro, è pur sempre possibile modificare il metodo _UPC della porta per far si che ritorni "GENG (Zero, Zero)" ma lo vedo solamente uno spreco di righe di codice, dal momento che è gia definito un metodo GUPC all'interno della tabella. Riguardo ciò, non è sbagliata come idea ma, dal momento che la sua è una scheda madre di 10 generazione Intel con chipset Z490, richiede solamente i seguenti SSDT: - SSDT-AWAC (dal momento che ha un clock AWAC che va disattivato) - SSDT-EC-USBX (come tutti gli hackintosh Intel di 6 generazione e successive) - SSDT-PLUG (come tutti gli hackintosh Intel) Analizzando il log di pmset, tramite il seguente comando, risulta che la causa del wake sia dovuta alla periferica CNVW (che per deduzione penso sia relativo allo slot m.2 WiFi chiave A+E presente sulla motherboard ma non occupato): pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to" Onestamente non so cosa pensare, dal momento che neanche via IORegistryExplorer, la periferica CNVW è presente. Ho pensato, così su due piedi, di aggiungere un eventuale SSDT-Disable_CNVW ma non so la sua efficacia... Sarebbe da testare Spero di aver chiarito eventuali dubbi e perchè no, se occorre qualche altro chiarimento sono più che disponibile ad aiutarti ^^ A presto dreamwhite

Proverò ad effettuare nuovamente l'enroll anche se mi sembra molto strano... Vi aggiorno UPDATE: tramite l'utility per l'enroll di Apple non sono riuscito a scaricare l'aggiornamento per la Beta 1 di macOS Bug Sure 11.3 Utilizzando Hack Check e eseguendo la procedura per l'enroll ho risolto. @Gengik84 deduco che molto banalmente il comando eseguito nel backend sia sudo /System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil enroll DeveloperSeed giusto?

Sono l'unico che non trova l'update nel catalog developer di Apple?

Sono riuscito ad aggiornare a Bug Sure 20D64 ma ho avuto qualche problema con la patch grafica... Più nello specifico, sul mio Dell Inspiron 5370 (i5-8250U + UHD 620) (EFI disponibile qui), con la patch grafica l'installazione si interrompeva ad un certo punto e panicava. Mettendo -igfxvesa, l'installazione ha proseguito fino a bloccarsi su IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0,. Rimuovendo -igfxvesa nuovamente, il boot funziona correttamente

Più che patch parlo di abbandonare clover e passare a OpenCore, un bootloader scritto da zero, con codice LIBERO e consultabile GRATUITAMENTE. Con OpenCore non c'è alcun inganno: le patch applicate dipendono solo da te, non vi sono patch prefabbricate come nel caso di Clover. Sei tu a decidere cosa mettere e cosa no. Se hai bisogno di aiuto per la conversione da Clover a OpenCore non esitare a chiedere aiuto qui sul forum ^^

Ciao ^^ grazie per avermi taggato Premesso che non vedo alcun motivo per usare Clover su una Z370, ma queste sono scelte dell'utente che rispetto ma non condivido assolutamente: sembra che la patch "AAPL,slot-name" su Big Sur dia problemi per quanto riguarda l'HEVC. Rimuovendo questa patch tutto funziona 🙂 Per come ho capito, grazie al briciolo di esperienza che ho nel campo dell'hackintoshing: le patch sono come gli alcolici: non devi mai esagerare

È già stato installato tempo fa e funzionava. Non riesco a capire il perché...

No, per il momento non ho effettuato alcun cambiamento della EFI che @carlo_67 mi ha gentilmente fatto 😕

Oh okay, grazie mille ^^ Abbiamo provato ad installare Big Sur, invano e abbiamo notato uno strano comportamento con l'installer di Catalina: una volta raggiunta la fine della barra di installazione dell'installer, il sistema non si riavvia e rimane bloccato: Premesso che macOS Catalina va più che bene per gli utilizzi comuni (ad oggi non vedo alcuna necessità di aggiornare a Big Sur se non per pura estetica), sarei curioso di scoprire il motivo del kernel-panic con l'installer di Big Sur. Pensi che debba applicare il KASLR Fix, nonostante su Catalina funzioni tutto?

Grazie mille per avermi risposto ^^ A giudicare dal config.plist deduco che la EFI sia per OpenCore 0.6.4, giusto? Se è così avrei un dubbio da chiarire nel mentre che testiamo la tua efi: Perchè è stato definito un dict "DataHub" dentro PlatformInfo? Ha senso tenerlo?

Salve a tutti, sto aiutando un amico nell'installazione di macOS Bug Sure 11.1 (20C69) sul seguente hardware: - CPU: Ryzen 5 3600 - GPU: Sapphire Nitro+ RX5700 Xt - Asus ROG X570-E Ho realizzato la EFI con OpenCore 0.6.5 e durante la fase di installazione il sistema panica, per motivi a noi sconosciuti. Allego una foto del kernel panic, così come la EFI (con seriali censurat i) che stiamo utilizzando: Avete idee sul perchè di questo kernel-panic? Grazie mille a tutti e buona domenica ^^ EFI.zip P.S. Installando macOS Catalina, non vi è alcun problema

Aggiornato con successo ad OpenCore 0.6.5 Sono curioso di sapere quando verrà approvato il refactoring di ControlMsrE2

@DS-1 buonasera e scusami se non ho fatto subito la EFI di OpenCore 0.6.4 (OpenCore 0.6.5 è uscito ma non sono ancora scaricabili le release). Gentilmente assicurati di aver configurato il BIOS come si deve, facendo attenzione ad abilitare XHCI Handoff per le USB, Legacy USB Support Inoltre effettua preventivamente un reset nvram usando il tool di OpenCore (una volta raggiunto il boot-picker, premi la barra spaziatrice e seleziona la voce "Reset NVRAM") Ecco a te la EFI in allegato EFI.zip UPDATE E' uscito OpenCore 0.6.5 così come le relative kext. Lascio a te il compito di aggiornare 😂

Grazie mille, appena mi è possibile vedo di farti una EFI di OpenCore, previa autorizzazione degli amministratori del forum. @Gengik84 attendo tue

Partiamo con ordine: 1. Su setup CoffeeLake + dGPU l'SMBIOS più appropriato è iMac19,1. per poter usufruire dell'accelerazione hardware devi abilitare l'intel quicksync modificando alcuni parametri dal BIOS: - primary display adaper (o "Initial Graphics Output"): PCIE - DMVT Pre-allocated: solitamente si mette 64MB per schermi FHD e 128MB per schermi 2K+. - DVMT Total Gfx Mem: MAX Puoi verificare la corretta accelerazione hardware utilizzando VideoProc. Per maggiori informazioni leggi qui: https://dortania.github.io/OpenCore-Post-Install/universal/drm.html#testing-hardware-acceleration-and-decoding 3. Preferisco VirtualSMC in quanto mantenuto e aggiornato costantemente da acidanthera, il team di sviluppo di OpenCore e la maggior parte dei kext che trovi in una EFI (giusto per citarne qualcuno: lilu, whatevergreen, intelmausi, applealc). La sostituzione è indolore ma richiede la completa rimozione di FakeSMC (e plugin). 4. Capisco. Non voglio accusare nessuno ma vorrei capire meglio le ragioni dietro a questa scelta: che vantaggi ci sono a definire un fake-als su un desktop sprovvisto di tale sensore? La stabilità del sistema viene compromessa senza tale sensore? Concludo dicendo che mi fido del lavoro di @Gengik84 , con cui ho avuto il piacere di discutere per il mio primo ed attuale hackintosh. Non è mia intenzione denigrarlo in alcuna maniera, ma piuttosto chiedere chiarimenti per i punti di cui sopra. Lo stesso discorso si applica allo staff intero di macos86 ^^ Detto questo, vi saluto cordialmente e attendo i file di log di opencore, qualora tu abbia intenzione di fare qualche prova ^^ See ya

Good morning, premesso che non ho minimamente intenzione di entrare in conflitto di interessi con te ed il forum, ma, stando a quanto mi è sempre stato detto qui e anche altrove, USBInjectAll va utilizzato solo nel momento in cui non vengono rilevate le porte USB. My fault che sono partito prevenuto 😃 My fault che non ho verificato preventivamente che la patch che hai messo nella sezione download sia collegata alla relativa guida. Come ho specificato nella "mia guida", non ho fatto altro che riscriverla in un linguaggio più chiaro e comprensibile a coloro che magari non masticano per bene le ACPI. Non è mia intenzione rubare il lavoro a chi ha fatto e dato tanto alla community 😃 Per quanto riguarda il discorso di OpenCore/Clover, non vedo alcun motivo di usare Clover nel 2021, soprattutto con quell'hardware così compatibile (parliamo di una ASRock Z370 Extreme 4, non di una Asus Z77 ._."). Idem per FakeSMC. VirtualSMC è molto più aggiornato rispetto a FakeSMC, e per tanto sarebbe saggio utilizzare VirtualSMC. Ci sono casi in cui è il caso di usare FakeSMC con hardware recente? Se si, potresti gentilmente elencarmeli? Grazie mille ^^

1. Evidentemente non avevi abilitato l'intel quicksync 2. Mh okay, seems fine 3. Meglio usare VirtualSMC :') 4. Non devi aggiungere dispositivi a caso perché "I VERI MAC HANNO QUESTI DISPOSITIVI". Sui Mac sono fisicamente presenti tali dispositivi, sugli hackintosh no. Se ti va, potresti allegare l'output di OpenCore Debug con sysreport attivo? Ho preparato una EFI a tal proposito: https://github.com/utopia-team/opencore-debug/releases/download/0.6.4/EFI.zip Onestamente ignoro il motivo per cui tu stia usando una EFI configurata relativamente male 😕 Per qualsiasi cosa feel free to ask

Salve a tutti, premesso che non ho seguito tanto questo topic avrei da chiedere alcune cose: 1. perchè usi iMacPro1,1 come SMBIOS? 2. perchè usi USBInjectAll? 3. perchè usi ancora fakesmc? 4. perchè hai un sensore ALS definito via ACPI? Grazie ^^

Buon anno a tutti e perdonatemi l'intrusione. Per quanto riguarda la mappatura delle porte USB non serve più utilizzare USBInjectAll (salvo casi rari ed eccezionali). A tal proposito ho scritto una guida per la mappatura delle porte USB. Se vuoi cimentarti nell'impresa ti lascio il link: Per qualsiasi problema non esitare a chiedere qui ^^