RTCMemoryFixup

[iCanaro]

RTCMemoryFixup https://github.com/lvs1974/RTCMemoryFixup/releases">https://github.com/lvs1974/RTCMemoryFixup/releases

 

 

 

Un'estensione del kernel open source che fornisce un modo per emulare alcuni offset nella memoria CMOS (RTC). Può aiutarti ad evitare alcuni conflitti tra osx AppleRTC e firmware / BIOS del tuo PC. Può anche aiutarti a scoprire in quali contorni hai un conflitto. Nella maggior parte dei casi è sufficiente fare il boot con alcuni offset in boot-arg, eseguire sleep, wake e restart. Se non vengono visualizzati errori CMOS o alcuni riavvii imprevisti, significa che sei riuscito a escludere gli offset CMOS in conflitto. Gli offset in boot-args rtcfx_exclude possono avere un valore compreso tra 00 e FF (prefisso 0xhout 0x) Attenzione: gli offset da 0 a 0D di solito sono più o meno "compatibili" e non dovrebbero causare conflitti. Gli offset da 0x80 a 0xAB vengono utilizzati per memorizzare alcune informazioni di ibernazione (IOHibernateRTCVariables). Se qualsiasi offset in questo intervallo causa un conflitto, è possibile escluderlo, ma la sospensione non funzionerà. Nel mio caso era solo l'offset: B2. Gli offset B0 - B4 sono usati per le funzionalità di PowerManagement, ma non funzionano comunque sugli hack)

 

 

 

Questo kext non è un plugin per Lilu, ma si basa ancora su alcuni metodi utili dalle librerie di Lilu, quindi devi inserire Lilu.kext nella cartella del progetto.

[iCanaro]

Hey boss mi/ci aiuti a tradurre il discorso tecnico sopra in qualcosa di più terra terra?!

 

A me pare di capire che questo kext potrebbe servire per avviare/installare con meno problematiche macOS. Poi in merito alla sospensione se anche questa non ti funzionerà ti potrebbe evitare dei potenziali conflitti che potrebbero causare riavvii o KP

 

Capisco che l'ho sintetizzata ai massimi livelli :D ma ho sparato una marea di ..zzate oppure ho vagamente inteso le potenzialità di questo kext?

[iCanaro]

v1.0.1 https://github.com/lvs1974/RTCMemoryFixup/releases/download/v.1.0.1/1.0.1.RELEASE.zip">https://github.com/lvs1974/RTCMemoryFix ... ELEASE.zip">https://github.com/lvs1974/RTCMemoryFixup/releases/download/v.1.0.1/1.0.1.RELEASE.zip

 

 

 

Critical bug has been fixed: prevent kext unloading

[iCanaro]

v1.0.2

 

 Wrong range start value in debug message has been fixed (thanks to nms42)

 

 

 

info e download: https://github.com/acidanthera/RTCMemoryFixup/releases">https://github.com/acidanthera/RTCMemoryFixup/releases

[iCanaro]

v1.0.3

 

Fixed compiling and loading on older OS

 

Fixed loading from /Library/Extensions

 

rtcfx_exclude property is read as string from RTC provider's properties

[iCanaro]

@here :D qualcuno lo usa questo kext???

 

se qualcuno lo usa che problema gli ha risolto?

 

 

 

Mi domando, visto che i big dell'hack hanno messo a disposizione questo kext, non credo siano diventati citrulli, quindi una sua applicazione e funzione utile l'avrà, cercavo di capire quando poteva essere utile inserirlo... nei miei hack con o senza non ho rilevato differenze... per cui se qualcuno lasciasse la sua esperienza sarebbe gradita ;)

[invisible00]

Fondamentalmente abbiamo offset CMOS fino al byte 256.
Le patch note(come anche fixRTC) limitano l'intero a 128 byte, il che di solito risolve già il problema.

Se nessuna delle patch note (come DSDT o Config Fix) è installata e viene utilizzato RTCMemoryFixUp, viene riutilizzata l'intera larghezza di banda (256 byte) e di conseguenza possono verificarsi nuovamente ripristini CMOS ecc. (Incompatibilità di AppleRTC e firmwareBIOS).

 

Il problema è trovare e definire gli offset problematici. Gli offset corrispondenti vengono quindi bloccati, ma RTCMemoryFixUp continua a simulare la lettura / scrittura su questi offset.

Non conosco alcun modo per leggere gli offset problematici da un registro o simili, il che significa testarlo. Se RTCMemoryFixUp è installato e la macchina si reimposta automaticamente dopo la sospensione / riavvio, vuol dire che stiamo ancora scrivendo su quegli offset che creano problemi, il che vuole anche dire che per trovare i settori bisogna andare per tentavi.

Gli offset 00-0D (0-13) non sono critici, non è necessario provarli. L'idea è di trovare prima il banco di memoria problematico (il primo va da 00-7F / 0-127(byte) e il secondo da 80-FF / 128-256(byte)) (entrambi hanno un problema nel caso peggiore).

Per questo escludiamo 13-127 tramite bootarg, ovvero rtcfx_exclude = 0D-7F e testiamo con sleep, wake e reboot. 

Se il problema è risolto, dobbiamo trovare più precisamente gli offset problematici tra 0D-7F.

Se il problema non viene risolto, testiamo il secondo banco, ovvero rtcfx_exclude = 80-FF .

Diciamo che il problema è stato risolto solo ora, ora possiamo continuare i test nell'area 80-FF (128-256byte).

Una tattica per evitare di dover testare ciascuna area individualmente è quella di dimezzare l'area per scoprire in quale metà del problema si trova. Ad esempio, ora è possibile utilizzare quanto segue per questo: rtcfx_exclude = 80-C0 . Se il problema non esiste neanche con questi esclusi, possiamo testare ulteriormente nell'intervallo 80-C0 (128-192) (ad es. Di nuovo la metà). Tuttavia, se il problema persiste, possiamo continuare a esaminare l'area C0-FF per trovare l'offset problematico (area). E così via fino a quando non si identificano gli offset problematici.

 

Questo e pressoché il modus operandi da seguire per utilizzare questo kext, almeno per ora, magari in qualche rilascio futuro si troverà un metodo per identificare i settori in maniera automatica.

Sto facendo attualmente delle prove, ma nel malaugurato caso che hai errori in più settori la situazione si complica 😭