amd Hackintosh AMD OpenCore

[Anto65]

Serenamente puoi puntare il dito, dopo un po che ci sbattevamo per far capire e inserire velocemente i device ho pensato a Configurator infatti non e' una cosa a lungo andare di base uso PlistEdit Pro come avrai spero potuto notare in qualche shoot🙂

[damiandrake]

56 minuti fa, carlo_67 ha scritto:

fai un ultima prova, lascia AppleALC e nel bootarg npci=xxxx più alcid 1

layout metti 01000000 

e cambia posizione di caricamento

di AppleALC, mettilo dopo lilu

 

 

prova anche togliendo WEG, che con la 710 non serve

 

45 minuti fa, carlo_67 ha scritto:

Poi una cosa Ma il verbose ti da sempre cosi,

il rallentamento all'avvio alle usb ci dovrebbe essere un fix

per quello

oppure vedi le impostazioni nel bios 

Comunque VooDoo è un ottima scelta

VoodooHDA.kext.zip 98 kB · 1 download

Ora provo con i tuoi consigli, poi provo a fixare le USB con il kext che consiglia Dortania (tanto devo sempre mapparle visto che ho anche 2 porte USB 3 che non funzionano su macOS). Cmq WEG serve per arrivare alla scrivania (senza quello rimango con una schermata nera dopo la fine del verbose)

[damiandrake]

1 ora fa, carlo_67 ha scritto:

fai un ultima prova, lascia AppleALC e nel bootarg npci=xxxx più alcid 1

layout metti 01000000 

e cambia posizione di caricamento

di AppleALC, mettilo dopo lilu

 

 

prova anche togliendo WEG, che con la 710 non serve

Provato anche così, niente da fare. Vado di VoodooHDA

[damiandrake]

Ragazzi ma ci credete che è bastato mettere VoodooHDA e tutto ha funzionato al primo colpo? Sono 3 giorni che tiro giù i santi per far funzionare sto benedetto audio, ora funziona tutto!

Edited March 4, 2021 by damiandrake

[Gengik84]

Il 3/3/2021 at 21:29, dreamwhite ha scritto:

2. Perchè non viene rispettato l'ordine di caricamento delle kext come scritto chiaramente nel codice sorgente di ocvalidate? (source)

Quello non è l'ordine obbligatorio di come devono essere inseriti e definiti i kext sul config... non c'entra nulla...  lol

 

[A23SS4NDRO]

8 minutes ago, Gengik84 said:

non c'entra nulla..

diciamo che i commenti un po' lo suggeriscono:

 

 

Però ho sentito opinioni differenti.. riporto alcune citazioni:

 

1)

Kext load order is determined based on dependency. First, all dependencies and CFBundleIdentifiers for all kexts to load are gathered and all parents within the Kexts folder are determined, then the list of kexts is walked - skipping and readding to the end of the list any child kext whose parent has not been added yet. This is repeated until all kexts have been added. As for the ExecutablePath not being filled in - injector kexts are plist-only. They have no executable, and as such, that field will be blank. The executable is determined based on the contents of the Info.plist of the kext, and verified before attempting to walk the list of kexts. This is neither an issue with your config or the software, and appears to be working as intended.

 

2)

Kext load order is specific - but only when comparing kexts that are dependent on each other. Lilu being first isn't a requirement - it just needs to load before any of its plugins. AppleALC and WhateverGreen are not dependent on each other, and as such, it doesn't matter which of them is first - but Lilu must be loaded before either of them as they both depend on it.

 

3)

Both OC Snapshot and the Clean snapshot also verify kext load order based on dependency checking and warn if you attempt to load kexts with duplicate bundle ids that overlap when comparing min/max kernel - [...] (Propertree) also ensures kext load order based on dependency checking, and will prompt if they're ordered incorrectly. Kext load order is verified on every snapshot, clean or otherwise.

 

4)

[...] (Propertree) also verifies kext load order - ensuring that all parents are loaded before children - and if the existing order is incorrect, it'll prompt you with an offer to fix it when snapshotting

 

 

 

 

[carlo_67]

16 minuti fa, Gengik84 ha scritto:

Quello non è l'ordine obbligatorio di come devono essere inseriti e definiti i kext sul config... non c'entra nulla...  lol

 

Intanto mette in ordine i kext essenziali tranqullamente

be prova da te e vedi che se togli lilu e il virtual 

e poi li inserisci trascinandoli, vedrai che non li mette ultimi, ma in poleposition😃

provare per credere, 

[A23SS4NDRO]

8 minutes ago, Gengik84 said:

non c'entra nulla..

diciamo che i commenti un po' lo suggeriscono:

 

 

Però ho sentito opinioni differenti.. riporto alcune citazioni:

 

1)

Kext load order is determined based on dependency. First, all dependencies and CFBundleIdentifiers for all kexts to load are gathered and all parents within the Kexts folder are determined, then the list of kexts is walked - skipping and readding to the end of the list any child kext whose parent has not been added yet. This is repeated until all kexts have been added. As for the ExecutablePath not being filled in - injector kexts are plist-only. They have no executable, and as such, that field will be blank. The executable is determined based on the contents of the Info.plist of the kext, and verified before attempting to walk the list of kexts. This is neither an issue with your config or the software, and appears to be working as intended.

 

2)

Kext load order is specific - but only when comparing kexts that are dependent on each other. Lilu being first isn't a requirement - it just needs to load before any of its plugins. AppleALC and WhateverGreen are not dependent on each other, and as such, it doesn't matter which of them is first - but Lilu must be loaded before either of them as they both depend on it.

 

3)

Both OC Snapshot and the Clean snapshot also verify kext load order based on dependency checking and warn if you attempt to load kexts with duplicate bundle ids that overlap when comparing min/max kernel - [...] (Propertree) also ensures kext load order based on dependency checking, and will prompt if they're ordered incorrectly. Kext load order is verified on every snapshot, clean or otherwise.

 

4)

[...] (Propertree) also verifies kext load order - ensuring that all parents are loaded before children - and if the existing order is incorrect, it'll prompt you with an offer to fix it when snapshotting

 

 

 

 

[Gengik84]

non è l'ordine dei kext sul config.

io posso mettere  per esempio:

Lilu

VirtualSMC

AppleALC

WEG

 

e va benissimo non è che è errato perchè sul codice di ocvalidate trovate WEG prima di AppleALC

[A23SS4NDRO]

On 3/3/2021 at 10:36 PM, damiandrake said:

è bastato mettere VoodooHDA

diciamo che è più una pezza che una soluzione

[Gengik84]

Quello che conta è lilu primo

poi è ovvio che il kext "madre" deve essere prima dell'eventuali plugins

[A23SS4NDRO]

1 minute ago, Gengik84 said:

trovate WEG prima di AppleALC

si ma non sono dipendenti tra loro quindi non cambia...

[Gengik84]

1 minuto fa, A23SS4NDRO ha scritto:

diciamo che è più una pezza che una soluzione

npci= è sempre stato un problema quindi di fatto non è una pezza in questo caso ma bensì una soluzione

[carlo_67]

stiamo dicendo la stessa cosa😆

Adesso, carlo_67 ha scritto:

stiamo dicendo la stessa cosa😆

per anni ho dovuto optare per quello

[A23SS4NDRO]

1 minute ago, Gengik84 said:

Quello che conta è lilu primo

Dipende, infatti come avevo citato prima:

3 minutes ago, A23SS4NDRO said:

Lilu being first isn't a requirement - it just needs to load before any of its plugins.

 

La regola generale de facto è "i plugin vanno dopo"

[Gengik84]

1 minuto fa, A23SS4NDRO ha scritto:

si ma non sono dipendenti tra loro quindi non cambia...

eh appunto..

Altrimenti si fa passare un obbligo di dichiarazione facendo di tutta l'erba un fascio ma non è così di fatto

non è il codice di ocvalidate da seguire alla lettera

Adesso, A23SS4NDRO ha scritto:

La regola generale de facto è "i plugin vanno dopo"

ecco si esatto, questo è quello che conta, ma alla fine l'ordine, se rispetti questo discorso che dici, è indifferente

con ordine intendo generale dei kext dichiarati sul config

conta "madre" e poi plugins

[Gengik84]

poi calcola che il codice è anche stato giustamente  scritto in alfabeto per molti versi, anche per renderlo migliore e decisamente più ordinato

[carlo_67]

comunque uso anche l'Opencore configurator

non sempre, quando compilo una efi da zero no, per fare cose veloci si

e non va' malaccio 

[Gengik84]

Adesso, carlo_67 ha scritto:

comunque uso anche l'Opencore configurator

non sempre, quando compilo una efi da zero si, per fare cose veloci si

e non va' malaccio 

sinceramente non lo so, mai usato

di fatto è vero che spesso è stata la causa di problemi ma questo non ora per OpenCore

ma anche per Clover

Sinceramente provai questo all'inizio quando uscì https://github.com/ic005k/QtOpenCoreConfig/releases

perchè mi è piaciuto subito il lavoro sull'altro progetto ossia plistEditor

Confrontando il config, successivamente averlo modificato, con un plist editor la struttura era corretta e per esempio non era ne sfalsata e ne modificata con tanto meno voci commentate -->#

e riaggiunte successivamente

[A23SS4NDRO]

4 minutes ago, carlo_67 said:

uso anche l'Opencore configurator

diciamo che il problema è che si inserisce in un contesto in cui la documentazione già ci sta, non è come clover che non hai un reference manual scritto come si deve - il config-sample.plist presente nel cloverv2.zip è penoso, etc

 

personalmente non lo vedo necessario anche perché non vedo cosa sta succedendo "under the hood" con un applicazione che non è opensource, e può fare anche danni

Edited March 6, 2021 by A23SS4NDRO

[Gengik84]

2 minuti fa, A23SS4NDRO ha scritto:

personalmente non lo vedo necessario anche perché non vedo cosa sta succedendo "under the hood" con un applicazione che non è opensource, e può fare anche danni

codesto è decisamente irrilevante, open source o no puoi sempre vedere cosa è stato fatto al plist

come nel mio esempio descritto sopra riguardo a quel progetto che di fatto oltretutto è open

basta modificare, salvare e poi aprire con un plistEditor, uno che preferisci

[A23SS4NDRO]

1 minute ago, Gengik84 said:

puoi sempre vedere cosa è stato fatto al plist

certo ma devi usare altri tool per farlo

Non è irrilevente che possa corrompere il plist secondo me..

 

these rarely respect OpenCore's configuration and even some like Mackie's will add Clover properties and corrupt plists!

[Gengik84]

ah si certo ma intendevo che puoi in caso vedere e verificare cosa può aver fatto di errato

questo può dar un idea se di fatto un configurator X altera la struttura, duplica la "chiavi" etc 🙂

per esempio CC lo fa, sempre fatto ossia commenta quello che c'è di originale invece di editarlo direttamente, andandolo poi a reinserire..spesso anche non rispettando il config orginale

infatti anche al tempo, su clover si può ben notare decisamente un config  maggiore rispetto all'originale, dovuto al tutto descritto sopra

[A23SS4NDRO]

22 minutes ago, Gengik84 said:

Quello che conta è lilu primo

in realtà se mettessi prima qualcosa del tipo prima FakeSMC e poi Lilu non sarebbe errato, addirittura lo stesso vale se metti prima RealtekRTL8111" e poi Lilu

1 minute ago, Gengik84 said:

ma intendevo che puoi in caso vedere e verificare cosa può aver fatto di errato

si certo ma a questo punto conviene direttamente andare a mano piuttosto che aprire un configurator e poi andare a vedere dove eventualmente ha fatto ehm.. "stupidaggini"

[Gengik84]

beh teoricamente anche si

il fatto è proprio come si diceva prima ossia la "madre" e poi il resto quindi considerando che Lilu è la base... del resto basta che sia appunto messo prima dei suoi derivati

nel tuo esempio sia FakeSMC che RTL8111 non sono "figli" di lilu quindi potrebbero stare dichiarati prima..giusto