A23SS4NDRO

ho risposto che non riesco bene a comprendere che cosa intendi con "Delete" = una volta (cosa una volta?) "Block" = persistente (ma stiamo parlando della stessa sezione che da Block ora si chiama Delete, che cosa è Block ora? Che cosa è persistente?) Capisco che sono duro di comprendonio finché la cosa non la capisco alla perfezione, ma il discorso è poco chiaro Che senso ha di esistere la sottosezione di NVRAM "Delete"? Solo per nascondere ciò che è aggiunto in Add? Null'altro?

Ma quale sarebbe il senso? Posso tranquillamente toglierle a mano le variabili dalla sezione Add senza che le blocco dalla sezione Delete

Block in sezione NVRAM non esiste più, dal momento che tale sezione è stata rinominata in "Delete Mi risulta ancora poco chiaro, quindi se una variabile NVRAM ad esempio "boot-args" è presente sia in Add che in Delete, allora durante il processo di avvio tali boot arg vengono aggiunte da Add, poi: - Delete le cancella per non farle risultare dal controllo nvram -p oppure -Non vengono neanche caricate/lette da macOS/OpenCore ecc, dal momento che boot-args viene "Bloccato/Cancellato" dalla sezione "Delete"?

Secondo me si piazza in una fascia di prezzo un po' "pointless" nel senso che chi cerca una CPU per workload pesanti sicuramente non prende una CPU 10C/20T ma almeno un 16C/32T o maggiori, e poi clock così alti non vengono raggiunti senza LN2, quindi praticamente un 9900K si comporta esattamente come un 10900K se gli togli due cores. Si forse avranno abbassato ancora di più il layer tra il "die" e i core effettivi cercando di fare un IHS ancora più capiente in termini di raffreddamento, ma comunque il cliente deve comprarsi una motherboard nuova, quindi se un 10700K era interessante per chi era su Z370 (magari aveva un 4c come l'8100) e pensava di fare un upgrade prendendosi un 9900K a 390 dollari (e.g. 10700K) ora non può più farlo perché deve spendersi almeno altri 160 euro per una Z490... Se dovessi rifarmi il PC aspetterei le prossime architetture come Willow Cove a 10nm e vedrei come Apple risponde ad Intel... Poi di questo passo, se questa Z490 sappiamo che già supporta Pcie Gen 4 e le CPU di 10Gen supportano max pcie gen 3, vuol dire che Intel vorrà starci non solo per gen 10 ma anche per gen 11 su Z490, cosa che allungherà ancora i tempi per fare uscire CPU con nuove architetture (a meno che Intel rilasci entrambe nello stesso anno, Rocket Lake - 14nm e Alder lake a 10nm su un altra motherboard diversa da Z490 ovvio, in cui il supporto per Z490 si fermerà tra Comet Lake e Rocket Lake) Vedi: intel roadmap si dovrà vedere se Apple continuerà a seguire questi cambi di achitettura, e lo vedremo soltanto quando usciranno i nuovi mac, cosa che ritengo poco probabile su CPU Comet Lake dal momento che scaldano parecchio, ed è nota Apple per i suoi thermal constraints.

Sinceramente anche se fosse aspetterei la mossa di Apple dal momento che l'architettura Comet Lake non è stata ancora scelta da Apple (si certo lo so che alla fine è sempre basata su skylake) Basti guardare che SMBIOS ha scelto il tipo che ha aperto il repository per capire che non è che ci capisce molto, dal momento che ha messo come SMBIOS MacBookAir9,1 che è Icelake, una architettura completamente differente

Non mi risulta molto chiaro quale sia la funzione della sezione del config "Delete" che trovate qui sotto. <key>NVRAM</key> <dict> <key>Add</key> <dict> <key>4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14</key> <dict> <key>DefaultBackgroundColor</key> <data>AAAAAA==</data> <key>UIScale</key> <data>AQ==</data> </dict> <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key> <dict> <key>SystemAudioVolume</key> <data>Rg==</data> <key>boot-args</key> <string></string> <key>csr-active-config</key> <data>AAAAAA==</data> <key>prev-lang:kbd</key> <string>en-GB:2</string> </dict> </dict> <key>Delete</key> <dict> <key>4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14</key> <array> <string>UIScale</string> <string>DefaultBackgroundColor</string> </array> <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key> <array> <string>SystemAudioVolume</string> </array> </dict> Il mio dubbio consiste in questo, e mi sono dato una sola spiegazione come risposta ma vorrei la vostra conferma Anche la configurazione sembra un po' vaga Delete Type: plist dict Description: Removes NVRAM variables from a map (plist dict) of GUIDs to an array (plist array) of variable names in plist string format. "Che senso avrebbe mettere la sezione Delete se posso tranquillamente non aggiungere la variabile nella sezione Add?" Quindi l'unica possibile risposta sarebbe questa: Le variabili NVRAM nella sezione Add vengono lette tutte da OpenCore (e kext associati, come le bootarg per weg) (e poi da macOS solo se non sono presenti su Delete?) Oppure: Le variabili NVRAM vengono lette tutte da macOS e da OpenCore, e la sezione "Delete" serve per non farle risultare al comando nvram -p quando si avvia macOS. Vorrei volentieri avere chiarimenti in merito alla funzione della sezione Delete e dove vanno a finire le variabili NVRAM descritte in quella sezione, e se sono presenti in quella sezione quando e da chi vengono lette... Grazie mille

Dovresti prendere tutti gli ssdt che utlilizzi (i rename _DSM non dovrebbero dare prolemi) e inserire in tali SSDT: DefinitionBlock ("", "SSDT", 2, "sometableID", "someOEMTableid", 0x00003000) { If (_OSI ("Darwin")) { // Put here the SSDT } } (quello che importa è aggiungere il condizionale "If (_OSI ("Darwin"))" non il DefinitionBlock, che deve rimanere quello che già hai, ecco) tale ragionamento dovrebbe essere applicato a tutte le tabelle, tranne quella per le USB che non causa problemi al Windows teoricamente... Ma se utilizzi altri rename/patch allora sei costretto ad avviare windows parendo dal boot menu senza passare per opencore...

No progress at all. Tried with SSDT Basic, returned the classic error at PciConfigurationEnd

quindi non hai la integrata attiva... vedrò se nella prossima release di catalina si riuscirà a risolvere....

ioreg -l | grep platform-id Posta il risultato del comando sopra, vediamo se dipende dalla iGPU on o off... Che smbios usi? Che release di Catania è? 19E287? Per vedere su che release sei clicca su about this Mac e clicca due volte sulla verisone di MacOS (es. 10.15.4 clicca due volte su 10.15.4)

Sisì certo era solo per un test e per vedere se dipende da 10.15.5 beta 3

A te su desktop funge il risveglio da Sleep? (p.s sei su 10.15.5 beta3? Puoi anche allegare la verisone di MacOS che stai usando 19Fecc..)

Niente, non cambia sempre stesso panic dopo lo Sleep... Si spegne e si riavvia con quel panic riportato sopra Quindi Sleep su Catalina non va per la maggior parte della gente? Le macchine di cui parli sono aggiornate all'ultima beta? È successo tra una delle tue che dopo aver aggiornato alla beta lo Sleep funzionava come funzionava su mojave (ossia alla perfezione)?

Ok prima provo con solo il quirk, siccome sono già su OpenCore. Vediamo se lo sleep funziona

Che consigli di fare quindi? Meglio tenersi su 19E287 (10.15.4 stable ma con problemi di sleep) oppure provare 10.15.5 beta3? Tu su che release (19Fqualcosa) di 10.15.5 stai? hai provato ad andare in sleep con macchine che hanno la iGPU off (dal momento che su questa build uso iMacPro1,1 per l'accelerazione video) Se riuscissi a fare il test con la build che ha una dGPU e una CPU con integrata off (forse quella con 8700k e vega56 nano?) potremmo vedere se hai gli stesso problemi che ho io - e confrontare anche il delta tra le versioni di Catalina che stanno sul tuo, potremmo isolare l'hardware (paragonandolo siccome simili config e smbios identici) Questo per vedere se un aggiornamento di macos può cambiare o meno la situazione

Ciao ragazzi, ulimamente su questo PC ho avuto alcuni problemi di Sleep, quando premo appunto sul tasto Sleep dal menu della mela succede che il pc riesce ad andare in sleep con il pulsantino di accensione che lampeggia ma non riesce a risvegliarsi (quindi si avvia normalmente) e ha un panic in reboot di questo tipo: Sleep Wake failure in EFI Failure code:: 0xffffffff 0x0000001f Please IGNORE the below stackshot ================================================================ Date/Time: 2020-05-16 14:49:34 +0200 OS Version: ??? ??? (Build ???) Architecture: x86_64 Report Version: 29 Data Source: Stackshots Shared Cache: 0xb45b000 9BFEAF21-C40C-3FD6-8D58-CF0CFEF02EB2 Event: Sleep Wake Failure Duration: 0.00s Steps: 1 Time Awake Since Boot: 19s Process: swd [295] Architecture: x86_64 Footprint: 420 KB Start time: 2020-05-16 14:49:34 +0200 End time: 2020-05-16 14:49:34 +0200 Num samples: 1 (1) Thread 0x7b7 1 sample (1) priority 4 (base 4) <thread QoS background (requested background), thread darwinbg, process darwinbg, IO tier 2> 1 start + 1 (libdyld.dylib + 109769) [0x7fff723c9cc9] 1 1 ??? [0x104028454] 1 1 ??? [0x1040281dd] 1 1 __stack_snapshot_with_config + 10 (libsystem_kernel.dylib + 135862) [0x7fff7252b2b6] 1 *1 ??? [0xffffff80002c8206] 1 *1 ??? [0xffffff80009875f7] 1 *1 ??? [0xffffff80008a0001] 1 *1 ??? [0xffffff80002eb9e7] (running) 1 Binary Images: 0x7fff723af000 - 0x7fff723e5fff libdyld.dylib (750.5) <D2A07EF5-A64B-3692-BE13-89DAA2EC5E80> /usr/lib/system/libdyld.dylib 0x7fff7250a000 - 0x7fff72536fff libsystem_kernel.dylib (6153.101.6) <E76440E1-D1E8-3D9A-8B47-D01F554FF1C4> /usr/lib/system/libsystem_kernel.dylib Vedo che in giro parecchie persone hanno avuto questo problema sia su mac ufficiali che non, e in particolare con 10.15.4 Fonti: Su macbook pro 16" https://mrmacintosh.com/10-15-4-update-wake-from-sleep-kernel-panic-in-16-mbpro-2019/ su reddit, uno con 8550U https://www.reddit.com/r/hackintosh/comments/fxt6hl/sleep_wake_failure_in_efi/ Sembra che aggiornare a 10.15.5 beta 3 risolva il problema, @iCanaro @Gengik84 avete sentito qualcosa a riguardo? Per ora sono su 10.15.4 19E287, qualcuno ha avuto problemi del genere?

Posta la EFI e togli tutto ciò che è inutile (via kext/drivers non necessari, usa ocquirks, sfoltendo anche il config.plist)

@Asgardo ti consiglio di vederti questo file nella sezione downloads e definire i connettori per le usb 3.0, 2.0 e porte interne e porte esterne con questo metodo, l'ho trovato molto utile

Quindi usbinjectall se ne frega dell'ssdt in pratica, anche se la tabella viene caricata prima del kext (o sbaglio?)

Estrailo con F4 da clover e posta qui la origin illibata, poi vediamo ioreg una volta che hai usbinjectall caricato e Port limit patch ma teoricamente se ha ssdt caricato non gli influisce la cosa?

Windows 10 non ha conflitti con i settaggi di macos. Mi raccomando mantieni i dischi separati, evita partizioni logiche Che tipo di errore? Manda una foto e allega la clover

Aggiungi questo alla tua firma, apri un topic separato apposito. Inoltre aggiorna il firmware dell'SSD e giusto che ci sei per parcondicio assicurati di stare sull'ultima versione del BIOS.

per questo hardware quella bootarg non dovrebbe servirti, ci sta una conigurazione di riferimento apposta di @SemanticA per lo stesso tuo hardware. se sei comunque curioso di sapere che cosa faccia quella bootarg, l'articolo sta qui Patching AppleGraphicsDevicePolicy.kext A long time ago (read seventeen months ago) I blogged about the changes in the AGDP (Apple Graphics Device Policy) and had to came up with a workaround for an issue in AppleGraphicsDevicePolicy.kext so that we could use a MacPro6,1 board-id/model combination, without the usual hang with a black screen. Today I like to present an alternative route for this and this time it is a patch that can be used with Clover’s kext patching feature. Here it is: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <key>KextsToPatch</key> <array> <dict> <key>Comment</key> <string>AppleGraphicsDevicePolicy (board-id) Patch (c) Pike R. Alpha</string> <key>Find</key> <data> Ym9hcmQtaWQ= </data> <key>Name</key> <string>AppleGraphicsDevicePolicy</string> <key>Replace</key> <data> Ym9hcmQtaXg= </data> </dict> </array> Basically what we do is search for “board-id” and replace it with “board-ix” – or anything that we want to use instead. Please give it a go and let me know if it works for you. Please note that this is not my patch for the AMD discrete graphics problems! Update: Folks. Let’s not reply to false copyright claims and other childish attacks from the same people who did that before. We know who they are… Blog article cleaned up and a note about the (AMD) discrete graphics added.

Quello però risulta utile con GPU di architettura RDNA come Navi, non per quando riguarda GCN (Vega)

Il bootarg agdpmod=pikera sostituisce il controllo board-id con board-ix se non erro, controlla il manuale di whatevergreen