-
Posts
330 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Events
Downloads
Everything posted by dreamwhite
-
Salve a tutti, apro questo topic per presentarvi uno dei miei progetti appena sfornati: ScanPolicyDecoder PREMESSA: il seguente programma è un fork del progetto CsrDecode di corpnewt Potete scaricare il progetto a questo link: https://github.com/utopia-team/ScanPolicyDecode Fatemi sapere cosa ne pensate e come posso migliorarlo eventualmente ^^
-
Ciao, non so se è stato già detto in giro ma a quanto pare è un bug di Big Sur. Per ovviare a ciò ho dovuto scaricare l'ultima versione di Python3 e ho lanciato direttamente lo script "buildapp-python3.command"
-
Okay, ho capito cosa intendi. In tal caso, disabilitando EnableWriteUnprotector e abilitando RebuildAppleMemoryMap+SyncRuntimePermissions la macchina non parte. Per poter bootare con RebuildAppleMemoryMap+SyncRuntimePermissions devo abilitare DevirtualiseMmio e abilitare la whitelist della regione 0xFF000000
-
Dunque, possiamo riassumere la questione molto brevemente partendo da queste considerazioni: - Dal log di OpenCore ho il MAT Support su 1 (il che significa che posso disabilitare EnableWriteUnprotector e abilitare SyncRuntimePermissions+RebuildAppleMemoryMap) - se modifico i quirk di cui sopra, il pc si blocca sulla stringa [EB|#LOG:EXITBS:START]. Per risolvere ciò devo abilitare DevirtualiseMmio e contemporaneamente whitelistare una regione MMIO (0xFF000000)
-
Perdonami hai ragione: ho allegato il log che testimoniava il MAT Support su 1, ma non quello con DEVMMIO su 1. In poche parole quello che ho fatto è stato: - mettere gli eseguibili di OpenCore 0.6.3 DBG - abilitare DevirtualiseMMIO - Impostare Target su 67 Una volta effettuato il primo boot (che chiaramente non è andato mai a buon fine), ho provveduto a whitelistare le regioni MMIO. Più nello specifico: essendo che DevirtualiseMmio rilevava 5 regioni, ho provveduto a disabilitare una regione per volta fino a superare la fase di pre-verbose con la 5 regione. Banalmente quello che ho applicato è descritto nella guida di dortania, come ho scritto anche sull'issue di acidanthera. Se mi dai qualche minuto ti allego il log con target 67 e DevirtualiseMmio attivo ^^ Update Ecco a te il log di OpenCore DBG: opencore-2020-12-10-164336.txt.zip Banalmente ho scritto tutte le regioni nella Mmiowhitelist e a turno le ho disabilitate. Solo facendo questa prova sono riuscito a dedurre che l'unica regione che non andava blacklistata è l'ultima (0xFF000000) :")
-
Grazie mille per avermi risposto ^^ Cercherò di essere breve: ho un Dell Inspiron 5370, e senza DevirtualiseMmio + MmioWhitelist, non posso avviare macOS con i quirk per il MAT Support su 1 (RebuildAppleMemoryMap e SyncRuntimePermissions). Il boot si freeza nella fase di "pre-verbose" [EB|#LOG:EXITBS:START]. Sono riuscito a ricavare le regioni Mmio e ho whitelistato l'unica regione a dare problemi. A tal proposito mi son chiesto "cosa succede se abilito i quirk per il mat support su 1?" e il PC si è avviato tranquillamente. Ho """documentato""" la vicenda sul bugtracker di acidanthera: https://github.com/acidanthera/bugtracker/issues/1348
-
Uh, ti dispiacerebbe linkarmi il topic in questione? Non ho capito se devo cercarlo in questo forum o altrove :haha:
-
Buongiorno a tutti ^^ Perdonate l'intrusione, volevo chiedervi: come posso individuare le regioni MMIO da whitelistare? Avete risorse in merito a come individuarle? Sul Configuration.pdf di OpenCore 0.6.3 non ho trovato granchè 😕 Grazie mille .-.
-
[ExternalDiskIcons] Perchè è altamente inutile
dreamwhite replied to dreamwhite's topic in General Discussion
Ci tenevo a precisarlo per coloro che si ostinano ad utilizzare la KernelPatch ^^ -
Salve a tutti, Vorrei far notare a tutti gli utilizzatori di questa patch... che esiste una soluzione migliore, come sottolineato proprio oggi da vit9696 nell'issue 1341 Link topic errato:
-
ah no? beh il firmware non è legato indissolubilmente al bootloader ed al relativo meccanismo di iniezione dell'smbios?
-
Salve a tutti, da ormai 1 anno che sono entrato nel mondo dell'hackintoshing, mi sono sempre incuriosito sul funzionamento del kext EFICheckDisabler. Per chi non lo sapesse, questo kext disabilita (in qualche modo) il controllo che viene effettuato sui veri Mac per prevenire modifiche firmware indesiderate. Vi lascio una foto dell'errore che potrebbe comparire La mia domanda è: su Clover questo kext era più o meno importante, visto il meccanismo di iniezione dell'SMBIOS. E su OpenCore invece? Ha ancora senso utilizzare questo kext? Grazie a tutti e buona giornata
-
Update nr. boh: probabilmente la causa per cui non riusciamo a mappare la porta DP della mobo è che l'utente utilizza un adattatore DP-HDMI. Per il momento non gli interessa il secondo monitor ma sta valutando l'acquisto (previa vendita della sua vecchia GPU 2070S) di una GPU compatibile
-
Update: siamo riusciti a mappare la porta HDMI (con1) con il BusID 1. Ora tocca alla displayport sperando che funzioni senza alcun problema
-
Perfetto! Ti farò sapere appena l'utente testa i seguenti config, che lascio qui allegati. Mi sono basato sul dump del framebuffer relativo all'AAPL,ig-platform-id 0x3E9B0000: ID: 3E9B0000, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000130B TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel HD Graphics CFL CRB Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 Configs.zip
-
Utilizzando il config.plist allegato ho riscontrato un problema strano: Se la boot mode è "UEFI only" il sistema riconosce solo 7MB di VRAM Se la boot mode è "UEFI + Legacy" il sistema va in blackscreen... config.plist.zip
-
No in effetti ha 64MB di DVMT da bios (purtroppo MSI è molto castrata da questo punto di vista). Domanda: ho notato che hackintool ha già la patch grafica per i connettori della stessa scheda madre dell'utente. E' il caso di provarla o faccio manualmente la patch grafica?
-
d'accordo dai. alla fine la cosa che farò è riapplicare l'iGPU bus id patching sperando che funzioni tutto come si deve
-
mmmmh ok. una domanda: la boot mode deve essere impostata su "UEFI + Legacy" o solo "UEFI"?
-
Quindi consigli di mettere il platform-id 0x3E9B0000 (visto che viene consigliato da dortania proprio in riferimento ai black-screen) + device-id? Se si, quale device-id devo mettere?
-
Buon pomeriggio a te Gengik, si: in effetti nel config da me allegato non risultano le patch ma fra i vari test effettuati ho caricato solo le seguenti proprietà: - AAPL,ig-platform-id 0x3E9B0007 o 0x3E9B0000 - framebuffer-patch-enable 01000000 Da ioreg risulta che il platform-id è 0xFFFFFFFF ioreg -l | grep ig-platform-id
-
Salve a tutti, sto assistendo un utente nella creazione del suo hackintosh. Di seguito le specifiche hardware: - CPU: Intel Core i7-9700K - Mobo: MSI Z390I Gaming Edge AC - GPU: Nvidia RTX 2070S (disabilitata da BIOS) Siamo riusciti ad installare Catalina 10.15.7 ma abbiamo problemi circa l'attivazione dell'accelerazione grafica. Siccome il setup è only-iGPU e la CPU è di generazione Coffee Lake, l'SMBIOS più appropriato (stando alle specifiche di everymac) è iMac19,2 ma abbiamo provato anche con iMac19,1. Abbiamo provato di tutto e di più per abilitare l'accelerazione grafica ma il platform-id (0x3E9B0007 o 0x3E9B0000) non viene minimamente rilevato. Vi allego la EFI qualora vi possa essere d'aiuto:EFI.zip Avete idee? Grazie mille e buona giornata a tutti
-
Non voglio alimentare il flame ma la soluzione ideale è quella che porta al medesimo risultato senza fare diecimila giri 😉
-
Per curiosità personale, sai cos'è il TRIM? Sai che interazioni possono esserci fra il firmware dell'ssd e il sistema operativo? Detto ciò, la soluzione ideale, come suggerita da @A23SS4NDRO è quella di applicare una property "built-in" "01" sul PciRoot Path dell'NVMe. Una soluzione pulita e non invasiva come magari potrebbe essere una patch kernel poco documentata
-
[Problemi iGPU] Gigabyte Z390 Designare ] i7-9700K
dreamwhite replied to dreamwhite's topic in Desktop
😅 non avevo specificato che nonostante abbia provato ad applicare la patch al framebuffer (tramite DeviceProperties e aggiungendo manualmente le voci), e ai connettori, comunque non riusciamo ad avere 1536MB di accelerazione grafica. Abbiamo provato i seguenti AAPL,ig-platform-id: - 0x3E9B0007 - 0x3E9B0000 con device-id 0x3E9B. Nonostante ciò, se proviamo a bootare abbiamo 31MB di accelerazione grafica, oppure il pc si riavvia. Sono consapevole che le Gigabyte abbiano problemi di Memory Video Map, ma non pensavo fossero così complesse da patchare. Come ultima prova ho generato la patch del framebuffer usando Hackintool (menù Patch, System Configs, Gigabyte, Z390 Designare v1 e v2): Mi verrebbe da provare ad impostare Macmini8,1 come SMBIOS ma non penso sia quello appropriato. Meglio iMac19,2 Grazie mille per l'aiuto