dreamwhite

Wait, non è mia intenzione offenderti ne screditare il tuo lavoro che apprezzo giorno dopo giorno, ma semplicemente adeguarsi agli standard che ci detta ACPICA (esempio: cercare ove possibile di usare la keyword Device al posto di Processor, così come usare solo _HID piuttosto che _ADR) C'è stato decisamente un fraintendimento. Col mio "Sarò felice di avere una tua risposta in merito" mi riferivo al perchè dell'utilizzo di 4 argomenti della funzione PMPM, dal momento che ne viene utilizzato solo ed esclusivamente uno (almeno all'interno dell'SSDT in questione). Obblighi non ce ne sono e mai ce ne saranno, semplicemente era una curiosità personale sapere la ragione arcana dietro a questi 4 argomenti... 🕊️

D'accordo, ma penso che tu sia d'accordo che se segui lo standard ACPICA 6.3, ti stai alle loro regole 😄 Sia chiaro: la funzionalità è sempre la stessa ma in informatica si cerca di utilizzare il minimo indispensabile per ottenere quel risultato e sinceramente non capisco perchè tu abbia aggiunto degli argomenti che di fatto non vengono utilizzati per niente. Sarò felice di avere una tua risposta in merito In ogni caso è bene che queste cose vengano documentate adeguatamente: #shareyourknowledge Concordo pienamente sul fatto che coloro che scrivo le ACPI OEM sono "fessi". Ci sono diecimila warning e forse dovuti ad una questione di "compatibilità" con i vari OS (ipotizzo (???))

Buonasera a tutti: sotto mio consiglio ho fatto aggiornare il PC di @dangia a macOS Catalina 10.15.5 e a grande sorpresa il sistema è andato in KP. Avete idee? I kext sono gli stessi proprio e mi sembra assurdo che abbia panicato. Allego video: Dal video mi sembra di capire che ci sia un problema relativo al kext relativo alle periferiche PCI. Avete idee? video.mp4

Uhm teoricamente non dovrebbero esserci warn o simili, sbaglio?

Come consigli di testare i layout id? Personalmente con un utente ho notato che andando a mettere il layout-id tramite DeviceProperties questi non viene caricato correttamente. testiamo tramite boot-arg alcid=XX?

Sulla grafica sono dubbioso in quanto di fatto non è stata applicata alcuna patch per il framebuffer della iGPU, ne tantomeno per la dGPU giacchè è compatibile. Il BIOS è stato configurato a dovere ma per maggiore sicurezza andremo a controllare nuovamente le opzioni. Sono fermamente convinto che il problema sia la chiavetta USB WiFi

Posso ipotizzare: hai provato a togliere la chiavetta WiFi? Ultimamente mi è capitato di avere problemi su altre macchine, che si sono risolti nel momento in cui non andavo ad utilizzare la chiavetta USB WiFi. Se ricordo bene hai la possibilità di collegarti tramite cavo LAN. Prova ad utilizzare solo il cavo LAN e vedi cosa cambia 🙂

Salve a tutti, io e @A23SS4NDROabbiamo aiutato @dangia nell'acquisto dei pezzi compatibili con macOS, nonchè l'installazione di macOS. Dopo un'odissea dovuta all'SSD che dava problemi, siamo riusciti a portare la macchina ad uno stato decente. Tuttavia, ci sono alcuni problemi da risolvere: - Audio basso dal jack 3.5mm (testeremo personalmente i layout-id) - Freeze improvvisi del sistema Per quanto riguarda la seconda problematica, nonostante l'accesso in lettura-scrittura all'MSR 0xE2 sia abilitato (CFG Lock disattivo), ogni tanto il sistema è soggetto a questi freeze. Avete qualche idea? Grazie mille

Buongiorno a tutti, abbiamo provato a rimpiazzare il driver AptioMemoryFix in favore di OpenRuntime+OCQuirks+OCQuirks.plist. Allego la EFI utilizzata. Mi verrebbe da pensare che sia un problema di internet recovery install, anche se questa teoria assurda non regge... Quanto meno dovrebbe bootare fino all'installer. Allego la foto del blocco: Può essere che la batteria sia la causa del blocco? Posso eventualmente provare a forzare un "Return (0x0F)" nel metodo _STA di BAT1? Non penso sia un problema di SMBIOS, anche se abbiamo messo un MBP16,1 per fare una prova assurda. Avete qualche idea? Grazie mille CLOVER.zip

Ci sono novità: impostando l'SMBIOS (per pura prova non per altro) su MacbookPro16,1, il sistema supera quel blocco relativo al caricamento delle tabelle ACPI. Tuttavia rimane fermo sulla mela (nonostante abbia messo il -v)

Mh capisco, allora provo a cambiare SMBIOS. Ciò potrebbe influire sul fatto che non carichi il DSDT?

Mmmmh, non penso che l'SMBIOS influisca sul caricamento del DSDT in alcun modo. Ho provato pure a caricare tramite ACPI/patched il DSDT.aml, con tanto di patch per la batteria applicata. Non so, ci sto perdendo le speranze quasi 😂

Ci sono aggiornamenti in merito al boot. Aggiornando il bios all'ultima versione disponibile, siamo riusciti a fare progressi. La EFI è valida in ogni caso?

Ti rispondo in ordine: 1. Non avevo analizzato le ACPI a prima vista, dunque non sapevo se fosse necessario o meno un rename per il controller EC / SSDT. Ora è stato rimosso 2. Assolutamente, altrimenti la batteria non verrebbe rilevata. Ho effettuato una prova togliendo tutti gli ssdt presenti sotto ACPI/patched, rimuovendo il rename "ECDV to EC" e impostato config.plist/Generate/PluginType=Yes Provando a bootare sembra che non vengano caricate per niente le tabelle ACPI, tra cui il DSDT.aml Allego foto: Butto una stupidata: fa che devo aggiornare il BIOS?

Ups, ero convinto si aprisse. Ricarico la EFI in allegato EFI.zip

Salve a tutti, sto guidando un utente nell'installazione di macOS Catalina sul laptop: MSI GE73 Raider RGB 8RF. Le sue specifiche sono le seguenti: CPU: i7-8750H GPU: GTX 1070, chiaramente non compatibile con macOS e disattivata tramite boot-argument "-wegnoegpu" Più precisamente stiamo riscontrando dei problemi durante il boot con Clover. Allego anche la EFI che ho creato personalmente oltre alle ACPI origin estratte con Clover usando F4 Sono ben accetti consigli Da quello che riesco a vedere, ci sono degli errori relativi al plugin-type della CPU, che ho applicato tramite SSDT-PLUG. Nonostante io abbia messo il rename "ECDV to EC" ho scoperto che il suo laptop non ha bisogno di alcun rename per l'EC in quanto è già presente quel device nel DSDT.aml. Avete idee su cosa possa essere? Grazie mille EFI.zip origin.7z

Buongiorno a tutti 🙂, dopo aver realizzato che ho sempre utilizzato una patch errata del framebuffer, sono riuscito a riapplicarne un'altra per la mia iGPU (Intel UHD Graphics 620 - KabyLake Reloaded generation) basandomi sulla guida menzionata precedentemente: ig-platform-id: 0000C087 device-id: C0870000 per i vari connettori ho eseguito la patch manualmente, analizzando il dump del framebuffer dell'ig-platform-id (usando conX-pipe, conX-type, conX-enable) In questo modo mi funzionano entrambe le uscite video (HDMI e DP (type-c)) compreso l'audio. Mi sto preparando mentalmente alla migrazione verso OpenCore, ma funziona tutto. L'ultimo step è studiare il funzionamento di OpenCanopy, ma non penso dovrebbe essere particolarmente difficile. La mia cartella di configurazione di Clover, è disponibile sul mio repository GitHub. Entro il mese di giugno, dopo essermi assicurato che tutto funzioni come si deve, provvederò a caricarla sul repository stesso. Grazie di tutto ❤️ dreamwhite

Ci sono diversi aggiornamenti relativi alla migrazione su OpenCore: - Il trackpad funziona semplicemente aggiungendo il rename "_OSI to XOSI" + SSDT-XOSI.aml - Mi sono appena reso conto che non ho mai effettuato la mappatura dei connettori video (HDMI e DP), con conseguente KP. Provvederò ad effettuarla seguendo questa guida Ancora grazie di tutto ❤️

Molto bene! Sono riuscito ad aggiustare l'audio, impostando su DeviceProperties il layout-id. Per l'SMBIOS ho risolto impostando UpdateSMBIOS su Custom (SMBIOS truncation risaputa). Tuttavia ora ho un piccolo problema: nel mio DSDT.aml patched su CLOVER il metodo _CRS del device TPD0, contiene solo Riportando la stessa modifica su OpenCore, il sistema non é in grado di bootare. Si ferma sulle famose schermate cui mi preoccupavo ad inizio thread. Avete qualche idea? Grazie mille

Buonasera, ci sono novità con OpenCore, soprattutto grazie a @marianopela: sono riuscito a bootare, bloccando il caricamento del mio DSDT custom. Proverò ad usare soltanto SSDT dove mi è possibile Il sistema funziona "bene", ma ho ancora da fixare: - SMBIOS - Audio - Trackpad In particolare, per quanto riguarda l'SMBIOS, dopo averlo settato correttamente da config, non mi viene caricato correttamente sul sistema. Allego foto: Infine: per il trackpad, giacchè ho applicato una patch direttamente da DSDT, genero un SSDT custom + rename via ACPI oppure ricreo il DSDT da capo? Grazie mille

😂 è proprio lo script che ho repostato sul mio repo GitHub. L'avevo visto su r/hackintosh tempo fa e me l'ero salvato. Purtroppo hanno segnalato come spam quel post...

Ahimè si, anzi è pure peggio se disabilito il caricamento del DSDT.aml. Vedo errori relativi a RP08, giusto per citarne uno. Nel DSDT.aml custom che ho fatto personalmente, ho rimosso tutte le periferiche che non sono utilizzate effettivamente su macOS, tipo gli RP, lasciando attivo solo RP06, che corrisponde alla mia DW1830. Non riesco a spiegarmi una cosa del genere purtroppo...

Posso azzardare a dire una sciocchezza? Fa che, siccome ha una MSI RX580, il VBIOS potrebbe dare questi leggeri problemi di incompatibilità con macOS?

Buongiorno a tutti, chiedo scusa se sto postando nella sezione sbagliata del forum. Apro questo thread sia per richiedere supporto, sia per eventuali miei aggiornamenti, circa la configurazione di OpenCore. Come da titolo, sto cercando di installare OpenCore 0.5.8 (release rilasciata oggi, 4 maggio 2020). Download RELEASE Insieme a me, in questa arcaica impresa ci sono @A23SS4NDRO e @marianopela che ringrazio per l'infinita pazienza. Preciso che ho un'installazione funzionante di Clover r5115, cui potete trovare la mia EFI sul mio repository GitHub Tra le svariate prove che ho effettuato, il boot si blocca sempre allo stesso punto. Allego foto: In più allego la mia cartella EFI di OpenCore:OC.zip Probabilmente avrò sbagliato qualcosa nella configurazione. In primis ho pensato invano che fosse un problema di Power Management della CPU, e ho testato SSDT-Basic.aml. In secundis ho pensato fosse un problema di "troppi SSDT", tant'è che ho abilitato il caricamento del solo DSDT.aml (che trovate nella EFI). Come ultima spiaggia ho pensato che fosse un problema di "troppe kext", tant'è che ho abilitato solo quelle strettamente necessarie al boot. Testerò in questi giorni diverse versioni della EFI (forse invano), fra cui: 1. Kext strettamente necessarie + -igfxvesa + DSDT.aml + SSDT-PLUG.aml In ogni caso, sapreste darmi qualche dritta? Grazie mille dreamwhite

D'accordo dai, allora proseguo con la fase di installazione del sistema operativo. Seguiranno aggiornamenti circa lo sblocco del CFG Lock e mappatura USB. Ancora grazie