A23SS4NDRO

Si esattamente, il resoconto della mappatura l'ho implementato nell'ssdt, ma se non funziona vuol dire che sbaglio qualcosa

Gliele ho scritte io quelle, c'è solo da verificare nell'ultimo SSDT che gli ho mandato se effettivamente ho inserito GENG nel posto giusto, per avere un paragone, quello vergine è questo SSDT-4-xh_cfsd4_vergine.aml.zip SSDT-4-xh_cfsd4.aml_mappato.zip Quello mappato che ho allegato è identico a quello di prima*

Ci avevamo lavorato tempo fa insieme Questi erano i valori che volevamo mappare, così do un'idea su come volevamo che l'ssdt caricasse le porte, ma a quanto pare a macOS non interessa nulla sia se blocchiamo la tabella originale con OEMTableID che Lenght (prendendo Lenght da origin) quindi forse sbagliamo qualcosa Comunque ecco qui i valori, alcune porte 2.0 le abbiamo disattivate per rientrare nel limite, quindi atteniamoci a questo piccolo riassunto Offline ports [ HS01 HS02 HS03 HS04 HS05 HS06 HS11 SS05 SS06 ] External 2.0 (back panel) [ HS09 HS10 HS13 HS14 ] Internal Proprietary ports (front panel and Bluetooth) [ HS07 HS08 HS12 SS07 SS08 ] External 3.0 (back panel) [ SS01 SS02 SS03 SS04 typec Without switch SS09 SS10 ] Last thing to be checked: if the typec connector (SS04 da tenere abilitato-HS04 da disabilitare) is with Switch (0x09) or without Switch (0x0A) SSDT-4-xh_cfsd4.aml.zip

Ho fatto alcuni dump da linux, possono essere utili per capire l'hardware che ci sta sotto, soprattutto per TB3 e le nuove usb xHCI Questo dump in HTML lshw.html.zip sembra abbastanza leggibile con un qualisiasi browser, tuttavia alcune info potrebbero mancare, come ad esempio alcuni sensori in questo dump HTML non ci sono, ma ci sono in quelli allegati qui sotto. Lspci semplice Lspci tree Verbose lspci Memory Map: I/O Ports

Teoricamente gli manca questo pezzo da nascondere... Lo vedo ds DSDT DefinitionBlock ("", "SSDT", 2, "CORP ", "SsdtEC", 0x00001000) { External (_SB_.PCI0.LPCB.EC0, DeviceObj) Scope (\_SB.PCI0.LPCB.EC0) { Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (0) } Else { Return (0x0F) } } } }

origin (before USB).zip

Update: chissà se qualcosa si smuove... https://github.com/acidanthera/WhateverGreen/pull/5#issuecomment-615455708

Hai ragione, la calma è la virtù dei forti... mi metteva solo un po' di pressione il fatto che la cosa potrebbe andare in cavalleria e forse neanche tra un anno sarà supportato, ma vedo in base ai vostri consigli che serve che tenga duro!! Il problema difatti è che non vorrei trovarmi a mani vuote lato portatile dal momento in cui con macOS mi trovo molto bene, quindi entro il periodo di scadenza della possibilità di restituzione del prodotto pensavo di capire se il problema che ho è un problema risolvibile con lo sviluppo (e quindi attendendo che i nuovi driver/kext etc si adattino) oppure è qualcosa di irrisolvibile Esattamente, questo è necessario che avvenga e ci sto proprio per questo - è inoltre fondamentale capire perché c'è quel blocco e se in effetti esiste un workaround... Detto ciò, individuato il blocco si individua il problema circostanziandolo il più possibile (può essere un problema di EC? Di clock RTC0 o AWAC Dal momento che se inserisco uno di quei due ssdt allora panica su CR2?) In sintesi se serve altro debug o se si hanno altri spunti per riflettere su una soluzione io ci sto e anche molto volentieri, sarebbe l'ottimale concludere la cosa entro i 14 giorni di garanzia per sapere "di che morte si deve morire" (so che molto probabilmente non avvierò MacOS in così poco tempo, ma almeno un abbozzo su quali sono le cause e le risoluzioni possibili di un problema - una volta individuato il blocco - sicuramente aiuterebbero a farmi sentire più tranquillo in merito) Detto ciò, vi ringrazio ancora perché supportate la ricerca, e per il fatto che avetr la pazienza di sentire anche me che borbotto 🤣

Volevo un attimo parlare con voi della risposta di vit9696 Quindi finché loro non adottano questi portatili con Ice Lake quali altri test possono essere effettuati? Come hanno ottenuto informazioni sui nuovi macbookair9,1 se non con le macchine stesse? Questo mi fa concludere che teoricamente hanno già una macchina con ice lake se hanno estratto seriali e if-platform-id... inoltre mentre tutto ciò che è sopra Z370 non è stato adottato da Apple, qui stiamo parlando di CPU effettivamente utilizzate nei MacBook... Qualora invece non hanno avuto bisogno di accesso fisico alle macchine come i MacBookAir9,1 per estrarre seriali, tabelle acpi etc per effettuare i test che loro ritengono necessari, deduco che l'accesso fisico alla macchina in questione sia fattibile anche per via remota (ad esempio se devo far girare un tool che faccia una panoramica di questo portatile per individuare il problema, o debba mandare tabelle eccetera, sono disponibile a farlo sia qui che dovunque per loro sia comodo). Forse se si riferisce alla mole di lavoro che hanno da fare e quindi non hanno tempo per poter stare appresso a nuovi hardware, il mio consiglio è quello di fare almeno una checklist che raccolga le informazioni di cui loro hanno bisogno per capire se una macchina è "supported" o meno - per poi mettere in coda la cosa e cercare di capire che fine devono fare i portatili IceLake, anche per il discorso TB3 integrato nella CPU

Inoltre avviando Linux ho notato un paio di Alert... È possibile trarne qualcosa su IRQ e quindi su SSDT-HPET?

Ho provato, stesso errore.... Secondo me il problema è proprio del Clock, lo ribadiscono anche qui Infatti, se non uso SSDT AWAC o SSDT RTC0 non ho quel panic, (mentre se ne uso almeno uno dei due o un DSDT tra quelli che ha fornito gengik allora ho appunto quel panic...) ma per il resto rimango sempre bloccato su PCI configuration End Leggendo in giro, su opencore troubleshooting sono issue come RTC, AWAC o HPET Di solito per blocchi su PciConfiguration end le cose da fare per l'appunto sono SSDT EC (aspetto volentieri di testare quello dinamico di @Gengik84 ) e anche un SSDT per il Clock che per adesso deve o essere riscritto oppure modificato a partire dai DSDT delle macchine con IceLake magari con anche vicino le ACPI dei mac originali...

Stamattina leggevo un po' in giro.... (link vecchio) https://wip.dortania.ml/OpenCore/config-laptop.plist/icelake.html https://dortania.github.io/vanilla-laptop-guide/OpenCore/config-laptop.plist/icelake.html Siccome avevo MAT support 1 allora avevo questo su Off, come aveva spiegato qui vit9696 https://github.com/acidanthera/bugtracker/issues/491 Siccome i test eseguiti finora avevano quel problema, che ne dite di provare con questo impostato su True ?

Ora manca solamente che si stacchino da HfsPlus.efi facendone uno loro da capo e lo implementino su OpenCore allo stesso modo e ci servirà solo OpenRuntime da quel momento in poi tra i driver fondamentali (poi tutto il resto è accessorio a meno di casi particolari di hardware datati) https://github.com/acidanthera/bugtracker/issues/659

Buongiorno a tutti, nuove info per quanto rigurarda AppleSupportPkg e lo sviluppo di OpenCore in merito... Ultimamente dava anche errori in compilazione, si vedeva che ci stavano lavorando quindi lo hanno implementato su OpenCore (reference) Lo hanno anche migliorato lato sicurezza, mettendo un settaggio a parte per evitare che qualsiasi versione venga caricata Come vedete è stato rimosso anche dai Sample.plist, quindi d'ora in poi si utilizzerà EnableJumpStart = True

Riprovato a partire da zero, lilubetaall più il DSDT, si blocca sempre lì. Dite che in futuro si troverà una soluzione oppure sono senza speranza?

Last login: Sun Apr 12 15:29:53 on ttys000 ale@Ales-iMac ~ % shasum /Volumes/Install\ macOS\ Catalina/Install\ macOS\ Catalina.app/Contents/SharedSupport/InstallESD.dmg 0e8079a008817a49c254a4d1e7f3a5132f4f7bb5 /Volumes/Install macOS Catalina/Install macOS Catalina.app/Contents/SharedSupport/InstallESD.dmg ale@Ales-iMac ~ % Last login: Sun Apr 12 19:57:37 on ttys000 ale@Ales-iMac ~ % shasum /Volumes/Install\ macOS\ Catalina/Install\ macOS\ Catalina.app/Contents/SharedSupport/BaseSystem.dmg 888f5e2ee62e0c191e4f0b572ee4248dbc5d198b /Volumes/Install macOS Catalina/Install macOS Catalina.app/Contents/SharedSupport/BaseSystem.dmg ale@Ales-iMac ~ %

Diciamo che putroppo non ho un 32/64 come il suo 3970X, ma la cosa l'ho testata già sul HP 4710s che ha un Core Duo da 2.10GHz (parliamo di un laptop del 2009) e con QEMU sono riuscito ad avviare High Sierra sotto debian, poi penso che promox sia proprio disegnato per la virtualizzazione anche se diciamo che è un'altra dimensione se non un altro universo 😁 Controllo shasum di BaseSystem.dmg e InstallESD.dmg subito, confrontandole qua https://github.com/notpeter/apple-installer-checksums

Io comunque non riesco ancora bene a capire in che fase del boot siamo bloccati e perché... Deve identificare la CPU? Eccola per avere uno storico EFI.zip

Sisi non metto in dubbio assolutamente l'impegno e la pazienza che ci stiamo mettendo, anzi era per renderlo pubbilico a tutti essendo proprio in prima linea in merito al Ice Lake Gli fa il solletico

NullCPU lo prendo dalla sezione Downloads del forum oppure da Corpnewt?

Apprezzerei volentieri se @Gengik84 riportasse gli sforzi effettuati nei DSDT che cortesemente mi ha fornito cercando di esporre più apertamente possibile il problema e i test effettuati Subito La EFI che ho postato di sopra va bene? Oppure devo togliere qualcosa? Ci sta il tuo DSDT, il tuo config con l'aggiunta di FixHeaders (alcuni CR2 li ho skippati con quello, quando dava FakeSMC: senza niente ) e FixOwnership (indicato dalla freccia blu del post di prima)

Apriamo un Issue su acidanthera sentiamo che ci dicono anche i russi?

Ecco la stessa situazione con Fixownership True e FakeSMC Come è possibile vedere quell'errore è andato via, ma secondo me c'è qualcosa che ci sfugge in merito a quel blocco CR2 EFI.zip

Provo con Fixownership true Riprovo con FakeSMC

Niente sempre Fault CR2