dreamwhite

Sul mio Dell Inspiron 5370 Monterey gira discretamente, incluso il trackpad con le gestures, la mappatura delle USB etc... L'unica cosa che al momento non funziona è il bluetooth della mia DW1830 il quale dipende da BrcmPatchRAM...

La butto li: hai scaricato ed installato l'ultimo aggiornamento di sicurezza di High Sierra? Di solito quando scarichi High Sierra tramite App Store/script come munki, non scarichi l'ultima versione ma una precedente (17G66 per la cronaca). Verifica gli aggiornamenti disponibili tramite App Store e riprova >)

Mi intrometto al volo, senza sviare il topic. Sono perfettamente d'accordo su quanto hai scritto, anche se, per ragioni pratiche, soprattutto con utenti che sono alle prime armi, è meglio fornire una "pappa scodellata" mirata ad ottenere le informazioni di debug per evitare di "perdere tempo" sulle operazioni più cruciali. Chi è più "smanettone" poi può tranquillamente analizzare in seguito la EFI e capire nello specifico quali sono le opzioni utili al debugging (in questo caso SysReport attivo e Target su 67). Ci sono pareri discordanti riguardo AppleXcpmCfgLock ma personalmente sono più per l'idea della soluzione pulita. macOS richiede il libero accesso all'MSR 0xE2? Si. Allora va sbloccato ove possibile. Le patch, in quanto tali, vanno comunque trattate con le pinzette, e gli utenti che sono "temerari" e vogliono sfidare la sorte, si assumono la piena responsabilità in caso di riavvii randomici e/o altro, come accaduto al sottoscritto. Purtroppo (e non ne faccio una colpa) la maggior parte degli utenti neanche sa nello specifico cosa sia il CFG Lock, nè tantomeno perchè serva disattivarlo. A tal proposito, proporrei di fare una sezione di Q&A sul forum, se non già presente, in cui si cerca di dare una risposta alle domande più comuni, del tipo: - Da dove si parte con la creazione di una EFI di OpenCore? Cosa mi occorre? - Cos'è il CFG Lock? - ecc... Cosa ne pensi? Saluti

Mi intrometto al volo: e se al posto di usare gitbook (che nella versione free è molto limitante) usaste github pages? Se la memoria non mi tradisce, Dortania usa github pages + un motore di rendering in vue (che io ricordi)

Buonasera a tutti 🙂 @Gengik84 volevo chiederti: ha senso impostare la voce "All" su true per quanto riguarda il drop della tabella ACPI delle USB?

Uhm addirittura disabilitare il VT-D? O_O Personalmente lo attivo sempre e se devo avviare OpenCore (e quindi macOS) mi assicuro che DisableIoMapper sia attivo 🙂 Avere il VT-D disattivo generalmente non causa chissà quali problemi, tuttavia se vuoi sperimentare passthrough di periferiche PCIe tramite KVM su Linux é indispensabile 🙂

Potresti allegare un dump dell'output.txt (ergo chiamato Section_PE32_Image.txt)? Che io ricordi non tutte le schede madri consentono lo sblocco CNVi

Yep I know ^^ Più che altro non ho mai avuto occasione di usare in prima persona ru.efi dal momento che le modifiche che ho applicato al mio laptop le ho fatte tramite modGRUBShell.efi usando setup_var ^^

Fantastica guida! I miei più sentiti complimenti per la guida di ru.efi ^^ Vorrei apportare una piccola correzione alle voci BIOS da modificare (premesso che la procedura per il patching è corretta): disabilitare alcune voci come: - Above 4G - CSM Support - Serial Port - SW Guard Extension - TPM State Chiaramente queste voci vanno modificate solo nel momento in cui non sono visibili nel BIOS lato GUI

Non voglio scatenare flame di alcun genere ma usare un bootloader che è la copia carbone di OpenCore (tutti i meccanismi di iniezione di OC sono stati implementati su Clover), per di più con alcune limitazioni (vedi NVRAM/Add e NVRAM/Delete che non sono minimamente presenti) è un po' da sadici. Problemi quali slide sono facilmente risolvibili con la guida che ha giustamente linkato @A23SS4NDRO. Non capisco questa ostilità nei confronti di OpenCore dal momento che non ci vuole una laurea in Ingegneria Nucleare per poter "assemblare" una EFI da zero. Software come ProperTree, in combinazione con SSDTTime e GenSMBIOS facilitano il lavoro in una maniera allucinante. Perché uno che inizia ora con hackintosh dovrebbe iniziare con un bootloader al tramonto che copia le features di OpenCore (risultando quindi in un mero duplicato senza alcun valore aggiunto o vantaggio)? Sarei curioso di sentire i pareri sia del team quadrifoglio che del team occhio blu della morte ahah Aggiungo: quale motivo pone in vantaggio l'utilizzo di un bootloader vecchio nei confronti di uno nuovo e rifinito più che bene dai developers?

Mi duole dirlo ma non ho mai avuto problemi per quanto riguarda i dispositivi della LAN 😅 Sono su un laptop con scheda WiFi (non penso influisca sul discorso LAN) senza porta LAN

Buonasera, stavo passando per caso sul forum quando mi sono imbattuto in questo topic 😂 Premesso che non voglio puntare il dito contro nessuno in particolare, ne scatenare flame di alcun genere, avrei alcune domande da porre: 1. Perchè viene usato OpenCore Configurator? E' risaputo da secoli che i configuratori a lungo andare possono causare problemi di compatibilità con il config.plist relativo alla versione X di OpenCore. Inoltre sono closed-source peggio di non so cosa e sarebbe mille volte più saggio usare alternative come ProperTree (che include la funzione di snapshot della EFI) o PListEditPlus 2. Perchè non viene rispettato l'ordine di caricamento delle kext come scritto chiaramente nel codice sorgente di ocvalidate? (source) Molto spesso mi è capitato di avere problemi con alcune kext proprio per l'ordine di caricamento delle stesse 😕

Veramente molto strano...

Effettivamente non è tanto normale... Secondo me sarebbe meglio effettuare un SysReport partendo da una EFI di OpenCore debug forse?

@Matteo88 buonasera, domanda: hai già identificato le porte USB tramite IOREG? Non sempre c'è una corrispondenza diretta fra HS03 e SS03 (vedi Gigabyte Z390 Aorus Pro) Nel caso tu non l'abbia fatto, disattiva temporaneamente la mappatura delle porte USB e procedi all'identificazione delle porte USB e nel caso aggiusta la mappatura

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?