A23SS4NDRO

È vero, di fatto abbiamo solo questo forum per poterne parlare, su insanely non ti si fila nessuno, vedi qua https://www.insanelymac.com/forum/topic/343640-lenovo-yoga-s740-14iil/ su acidanthera continuano a rispondere che "Pretty much nobody here cares about the hardware we do not have. Especially when it needs extra work that has little benefits."

Ho capito... Come mai li vedo poco entusiasti di provare con hardware nuovo? (adottato ufficialmente da Apple, non stiamo parlando di Z390 o AMD) Secondo il mio modesto pensiero, finché gli sviluppatori non fanno chiarezza o ci aiutano anche loro oltre all'infinita pazienza che ci stai mettendo tu, sarà elaborato (secondo me quasi impossibile) andare avanti. Ho provato anche a chiedergli sempre in quell'issue, numero 832 su bugtracker, quali fossero le circostanze che potessero fare sì che acidanthera iniziasse a cimentarsi nel debug di queste nuove piattaforme, ma mi hanno proprio risposto mandando mi aff {censored} al posto di rispondere alla domanda che gli avevo fatto, ossia quando e come possiamo aiutare per fornirgli gli strumenti per fare debug. https://github.com/acidanthera/bugtracker/issues/832#issuecomment-615248243

Secondo me finché vit e acidanthera non decidono di collaborare è difficile farsi strada https://github.com/acidanthera/bugtracker/issues/978#issuecomment-643790587 Poi la domanda che mi faccio è... serve che rifanno da capo il reverse engineerign dei driver intel che stanno su macOS dal momento che hanno completamente cambiato la grafica con le nuove iGPU basate su Sunny Cove?

Quell'SMBIOS non corrisponde ad un macbook con IceLake, ma con architettura precedente a 14nm, CoffeLake Il più corretto a livello di CPU sarebbe il 16,2 https://ark.intel.com/content/www/us/en/ark/compare.html?productIds=196593,196597

Ciao ragazzi, buona domenica a tutti.. Quest'oggi volevo esporvi questa notizia mi ha lasciato senza parole... È incredibile che certa gente sia in grado di commercializzare lavori open source, l'articolo contiene anche la risposta di Acidanthera. https://www.macrumors.com/2020/06/13/opencore-hackintosh/ Ci tenevo a condividerlo con voi...

Remove the "Apple" folder inside your EFI, and post it here. No need to rely on Google Drive Thanks

O metti SSDT-Basic che trovi nella sezione download, oppure compila questo https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-PMC.dsl

Please share your EFI folder 🙂 So the problem was the NVMe? you said that installing on Micron 2200 is not possible... I have a Samsung NVMe

Rimanda anche l'ultima EFI che utilizzi, Grazie

Ciao, bene che hai installato, ti dò qualche consiglio per sfoltire un po' il tutto... 1) vedo che usi clover, ma non l'ultima versione... vedi qua https://github.com/cloverhackycolor/cloverbootloader/releases per aggiornare puoi usare o il pacchetto .zip (CloverV2-5xxx.zip) e quindi sostituisci BOOTX64.efi e CLOVERX64.efi (che sono in realtà lo stesso file .efi ma in due dir separate) 2) rimuovi il .app WhateverName da /EFI/CLOVER/kext/Other, non è un kext 3) VoodooPS2 di acidanthera non ti funziona? vedi qui se sei curioso VoodooPS2 4) Hai tentato a usare virtualSMC (di solito FakeSMC si usa per hw datati, quindi immagino che la scelta che tu hai fatto abbia in qualche modo un senso, ma tanto vale provare) 5) UsbInjectAll se non ti serve e vedi tutte le USB su ioreg allora lo toglierei, altrimenti farei la mappatura 6) Non ci sta WhateverGreen vedi qua 7) sicuramente ci sono dei drivers da controllare/sfoltire, ad esempio serve capire se avvi puramente senza la necessità della cartella drivers/BIOS oppure se la utilizzi effettivamente quella cartella per avviare, che CPU ha il tuo portatile? È per caso un Ivy Bridge? No sembra una CPU 1st gen. tieni la cartella BIOS, forse non ti serve quella UEFI. A scansa equivoci puoi fare un test da USB per vedere se avvii o meno senza la cartella drivers/BIOS, ma non credo che tu riesca a vedere delle partizioni.... poi pensiamo a sfoltire la cartella drivers/UEFI (o a rimuoverla completamente - dal momento che non fai avvii UEFI) Intanto fai questi test, poi pensiamo a patch framebuffer eccetera una volta che hai messo whatevergreen e sappiamo il modello della tua CPU

OpenCore 0.5.9, HP CE2072NL

Proprio questa è una dimostrazione, ero obbligato ad usarla quell'app, e di fatto è una delle ulteriori lacune... Penso che come tutti, finche Slice non ha pensato di pubblicare CloverV2-5xxx.zip, o per quelli che pensavano di non usare quel tool ed appoggiarsi al .pkg (che fornisce un'abbozzo di un config.plist e scrive sempre in /EFI-Backups, anche se l'utente non vuole, e non ha modo di disattivare quella feature) o config-sample.plist che esce da CloverV2 (mai visto nessuno) - proprio per questi motivi, che di fatto non c'era un plist strutturato come quello di OpenCore - ero obbligato ad utilizzare un tool proprietario, che per quanto riguarda OpenCore la stesso dev ha rifatto un tool analogo ora altamente sconsigliato... Se avessero potuto fornire qualcosa come un sample fatto come si deve, non ci sarebbe stato bisogno di quel tool, e questo discorso ribadisce il fatto che manca la documentazione scritta bene. Acidanthera di fatto il Sample.plist lo mette in Docs, e ogni settaggio è spiegato e aggiornato, senza bisogno di "configurators" o di lavoro preso dagli altri (es. MacInfoPkg che è integrato in Clover configurator preso da acidanthera che ha fatto il reverse engineering dei seriali delle macchine Apple) come puoi vedere dai messaggi all'inizio del post, oltre a quel kext quegli errori dipendono dalla scrittura su RTC, ho menzionato gli issue sopra, e ho fatto vedere come quell'errore ha avuto un workaround, e in quel caso ci ha investito tempo vit9696 con rtc-blacklist in NVRAM e DisableRtcChecksum tra i quirks, mentre clover ha solo AppleaRTC per quell'errore specifico, e spesso neanche funziona. Poi ci può stare tutto, ha sbagliato a mettere i driver, kext eccetera, ma quell'errore ritengo possa essere risolto se si usano i tool supportati dagli sviluppatori che leggono gli issue e dedicano il loro tempo per fare debug in primis, e scrivere documentazione. Si ma ti faccio un esempio: uno non potrà mai colmare le proprie lacune ad esempio in astrofisica dallo tramite lo strumento che utilizza (e.g. il telescopio), non potrà a maggior ragione colmarle se non ha i libri per imparare, studiare, sperimentare i principi che studia. Altrimenti non ci sarebbe neanche necessità di condividere il progetto su github per renderlo opensource e aperto a tutti, gli utenti possono contribuire allo sviluppo con i test nelle proprie piattaforme, ma prima devono avere un manuale di rifermento per capire con che cosa hanno a che fare, non è che si vanno a rileggere tutto il sorgente da zero e capiscono da soli cosa impostare e dove farlo e in che occasione farlo... Se acidanthera progredisce con il progetto è proprio perché il fatto che la cosa è accessibile e leggibile da parte di tutti, tutti possono imparare qualcosa, già dal leggere Configuration.pdf. Altrimenti dovremmo essere tutti degli sviluppatori che lavorano su piattaforme come EDKII e tianocore per poter segnalare un issue o qualcosa del genere, invece ci sono persone che segnalano problemi anche non avendo queste conoscenze ma con almeno alle spalle una corretta configurazione del config.plist, cosa che non sarebbe possibile lato clover con le lacune sulla documentazione. Ripeto, qui non sto assegnando "colpe", come ho scritto qua la tesi che sto sostenendo non è che "clover fa schifo" o "clover è il colpevole", ma sto dicendo che non aiuta sicuramente il beginner a capire cosa sta facendo. Il configuration.pdf non sarà mai abbastanza ma è già qualcosa, e poi le guide che stanno su https://github.com/dortania che sono anche state di nostra ispirazione sicuramente avranno contribuito ad una comprensione più vera di quello che succede sotto il "cofano". E inoltre, mi dispiace di essere frainteso - qui non sto "vendendo un prodotto" ma sto consigliando di iniziare con OpenCore per la documentazione che ci sta dietro: non sto dicendo "guarda che su opencore ci sta uno sconto sulla facilità del 50%, ma solo per questo mese!"... no anzi tutto il contrario: sto dicendo che se vuoi iniziare con qualcosa, e vuoi iniziare seriamente, una buona base te la offre quel bootloader, dal momento in cui è molto meglio documentato. il mio intento era solo aiutarlo a trovare il workaround ai problemi di RTC già visti in https://github.com/acidanthera/bugtracker , e proprio lì le persone ci hanno lavorato e hanno trovato un workaround. Forse ci sta anche per clover, ma non vedo nessun issue che esplichi debug o solizioni proposte. Ribadisco, non biasimo "clover in sé ", ma sono dispiaciuto dal fatto che non ci sia la documentazione e che ogni tentativo fatto per chiederla è stato rifiutato. fine del mio OT, spero che il valore della documentazione non passi come qualcosa di scontato, ma anzi è il punto di partenza per capirne qualcosa, cosa che sta alla base della filosofia del forum.

E ovviamente come menzionato sopra, questo risulta in reazioni di questo tipo, sempre da vit9696

Ce ne sono a tonnellate di esempi di vit9696 https://github.com/acidanthera/bugtracker/issues/966#issuecomment-641358695

io non sto parlando di "colpe", sto dicendo che su clover la mancanza di documentazione sicuramente non giova nessuno, anche me che avrei voluto imparare di più su quel bootloader ora meno mantenuto rispetto a quanto lo è opencore. non si tratta solamente di capire quali driver utilizzare, ma soprattutto com'è strutturato il config.plist, quali settaggi aggiungono/tolgono tra le versioni, una spiegazione dettagliata per ogni singola voce non ci sta. Oltre al fatto che senza il tool di mackie Essendo la definizione di "facile" soggettiva, io trovo più facile quello che è più chiaro. Per me è inaccettabile doversi appoggiare ad un tool esterno come clover configurator (closed-source) per avere una documentazione non aggiornata e non ufficiale e fatta male, (nel senso che anche se ci metti la freccetta e vedi i consigli che spuntano, non sono sufficienti tali informazioni per avere un'idea di cosa fa quel settaggio) faccio un esempio di documentazione errata. Uno nuovo inizia a costruire la propria EFI e non ne sa nulla di CFG Lock eccetera, magari ha un portatile con CPU>4th gen e sappiamo che non è per niente facile sbloccarlo. si studia ogni piccolo settaggio, ecco la documentazione relativa KernelPM. "Kernel power management patch for haswell with locked msrs. Works with 10.8.5 and 10.9 kernels." Cose che non apprezzo di queste descrizioni inesaustive: -Non è aggiornata (menziona kernel vecchi) -Non specifica di quale kext va a fare la patch -Non dice se ci sta un workaround a questa patch per poterla evitare -Non dice quale sia il registro che ha questa protezione di scrittura (MSR 0xE2) -Non dice quale tool potrebbe essere d'aiuto per vedere se questa protezione sussiste, (VerifyMSRE2.efi) né dice come sbloccarlo. un secondo esempio... mancanza di informazioni per ogni patch DSDT, sostituita con un generico: "This parameter represents a whole set of DSDT patches which can be activated individually" traduzione: "questo parametro rappresenta un insieme intero di patch DSDT che possono essere attivate individualmente" Io ora mi chiedo: Dove sono descritte tutte quelle patch che cosa fanno e perché servono, e quando servono? Non sono l'unico che si lamenta del fatto che non ci sia documentazione scritta bene. Ecco altri esempi https://github.com/CloverHackyColor/CloverBootloader/issues/20 flaggati entrambi come "won't fix" cioè "non lo aggiustiamo", nel senso che non la vorranno fornire tale documentazione ufficiale. https://github.com/CloverHackyColor/CloverBootloader/issues/54 Se dovessi insegnare a qualcuno qualcosa di questo campo, sicuramente non consiglierei Clover non perché "non funziona" ma proprio per la disinformazione, perché tra un aggiornamento e l'altro potresti non avviare più e posso testimoniarlo per esperienza che è successo, basti guardare le release tra la 5109 e la 5114, che venivano flaggate come "latest release" e la precedente come "pre-release", al posto di avvisare gli utenti che quella versione sarebbe stata instabile fin dall'inizio, non flaggandola fin dall'inizio come Pre-release. Lo stesso è successo con la release di 10.15.4, dove utenti senza CFG Lock sbloccato (forse ne erano anche ignari di cosa fosse, dal momento che non ci sta documentazione dal lato di clover che spiega cosa faccia KernelPM) si sono trovati con la patch che non funzionava più. source: https://www.reddit.com/r/hackintosh/comments/fo9bfv/macos_10154_update/ Se personalmente ho imparato qualcosa, prima difatti menzionavo KernelPM, l'ho imparato da qui. Notiamo la differenza, il livello di approfondimento, la procedura che illustra come sbloccare tale registro, gli effetti collaterali che si generano se si usa quella patch, ci sono riferimenti a degli issue già risolti... Per chi lo volesse in italiano, diversi utenti del forum hanno investito il loro tempo per la traduzione in italiano di quel documento http://macos86.it/OpenCore/#/KERNEL/QuirkProperties Clover per me se non viene supportato lato documentazione, e se gli sviluppatori non lo riscrivono in maniera più al passo con i tempi, non è un'opzione valida per iniziare ad imparare qualcosa. Qualche giorno fa su applelife ho anche letto qual era l'opinione di vit9696 in merito a clover... https://applelife.ru/threads/opencore-obsuzhdenie-i-ustanovka.2944066/page-303

Questo di certo, ma allo stesso modo nessun bootloader potrà mai essere compreso senza documentazione almeno in Inglese, almeno aggiornata

Secondo me dovrebbe iniziare a studiare direttamente con OpenCore che è documentato molto meglio in confronto a clover, quando uno apre clover configurator non da dove raccapezzarsi mentre con OpenCore ogni quirk e documentato, aggiornato, approfondito, molto più seguito

provami queste due, che il portatile non l'ho più a disposizione per me in questo periodo EFI-V2.zip EFI-V1.zip

Poi hai fatto un po' un pastrocchio con i drivers UEFI - sarebbe da togliere emovariable, Datahub, audioDxe e VirtualSmc.efi

Come mai utilizzi clover? con OpenCore non riesci ad entrare nell'intaller grafico?

Allega la EFI in uso per avere una history tracking delle versioni

Esegue un Reset della NVRAM per assucurarsi che non ci siano variabili "residue" per aver usato altri driver UEFI (*.efi) non idonei https://en.wikipedia.org/wiki/Non-volatile_random-access_memory

Consiglio di rifare l'installer, quel VM SwapSystem is ON non mi convince

UPDATE: con questo layout ID mancava l'audio dopo lo sleep sugli speaker main, si sentiva solo in cuffia. quindi ho provato gli altri che erano consigliati qui E il layout-id "0D000000" che corrisponde a 13 come number, funziona anche dopo lo sleep, sia in cuffia che gli speaker integrati

Disabilita la voce "CFG Lock" Puoi abilitare "Intel virtualization tech" e lasciare disabilitato "intel VT-d tech" Per ulteriori chiarimenti... ricontrolla tutti i tuoi settaggi che è meglio