A volte ritornano, e proprio il developer Estwald, papà di Iris Manager ha rilasciato un aggiornamento ufficiale del plugin system manager.

Sembra che ci sia del malcontento da parte dello sviluppatore Orion che chiede l’inclusione dei giusti crediti per le versioni aggiornate rilasciate nei mesi scorsi.

Bisogna comunque precisare come l’intero codice sorgente sia stato scritto da Estwald stesso, e che Orion abbia solo in parte implementato i nuovi payload che potrebbero comunque risultare uguali.

[stextbox id=”alert”]Attenzione: Il seguente metodo non è stato testato dallo staff, come anche il developer Estwald consiglia di seguire tutte le dovute precauzioni, non dovrebbero esserci problemi, al massimo si potrebbe andare incontro ad un semibrick.[/stextbox]

Ma che cosa è il System Manager? Il System Manager (sm.self) è un applicazione eseguita in background attraverso l’uso di un file patchato (sys_init_osd) all’interno della PS3.

Il core purtroppo non supporta l’emulazione “bdemu”, questa è l’unica pecca che ci potrebbe portare a preferire una versione Cobra di un Custom Firmware.

La caratteristica principale di questo core, è che può essere eseguito con vsh.self per evitare la di sincronizzazione del controller per esempio, con il flag “Install2” si può  installare il file sm.self o il new_core.self (un aggiornamento).

Per lavorare come il core di Miralatijera senza passare per vsh.self esistono due modi, un metodo temporaneo (caricare la flag “install” su pendrive) ed uno “onboot” (caricare la flag “boot_on” su pendrive, questa verrà scritta in modo permanente sulla dev_flash).

Il core può arrivare a generare tre tipi di log sulla pendrive “emergency_log.txt” (si creerà solo se non sarà possibile caricare il file vsh.self) “install_log.txt” (si creerà quando verranno installati i file con install/install2) e “core_log.txt” (log classico).

In linea di massima, il core evita la generazione dei registri tranne in determinati casi (installazione o emergenza) o se si aggiunge il flag “verbose”. Questo perché di solito i registri non sono poi cosi importanti.

Il System manager viene sempre eseguito in background ed è costituito essenzialmente da tre funzioni distinte.

1. Il principale dove il ciclo viene racchiuso nella durata di 1 ms (millisecondo) ricevendo i comandi tramite l’indirizzo 0×450 del LV2 con cui configurare l’applicazione.
2. Il FanCtrl_Thread che pone le stesse funzioni del carico utile, la differenza sostanziale è che a differenza del payload, ciò non incide direttamente sui processi.
3. Infine la UsbWakeup_Thread che raccoglie 3 modalità di funzionamento e fondamentalmente si occupa di “svegliare” i dispositivi USB che tendono a “dormire” per mancanza di utilizzo, causando problemi nei giochi.

Vediamo di seguito un riassunto delle Flag attualmente supportate:

• boot_on: abilita il lavoro di base prima del carico vsh.self (come su MiralaTijera)
• boot_off: rende il core in grado di lavorare in background con vsh.self.
• install: installa i file necessari prima che venga caricato il file vsh.self (più sicuro).
• install2: procede all’installazione dei file in un secondo momento con vsh.self.
• removesm: elimina il file sm.self dalla directory dev_flash.
• ignoresm: ignora il caricamento del file sm.self ( può essere utile come test, in caso di crash, nel caso il system manager provochi un qualche danno, il file in ogni caso non verrà eliminato).
• verbose: attiva il registro completo.

Il plugin funziona egregiamente anche su Custom Firmware Cobra, anche se il suo utilizzo potrebbe “sminuire” di fronte all’applicazione realizzata da Deank, il plugin webMAN infatti non fa uso dell’applicazione Fan Control di Estwald, il controllo della ventola è stato completamente rielaborato dalla versione 1.28 utilizzando una sola semplice syscall (la sys_sm_set_fan_policy).

A causa del modo in cui lavorava il metodo di comando per la ventola (che andava ad intercettare le sysevents/communication) la console veniva sottoposta ad un lavoro più ‘pesante’ per quasi nessun motivo, ciò comportava temperature elevate per la CPU.

Ora dopo aver reso il lavoro più leggero (controllo della temperatura e velocità della ventola fixata), la console sarà meno stressata riuscendo a mantenere più basse le temperature.

I LED indicano quanto segue

• Led Giallo fisso: temperatura uguale o inferiore a 70 gradi
• Led giallo/verde lampeggiante temperatura superiore o uguale a 70 gradi
• Led rosso/giallo/verde lampeggiante temperatura superiore o uguale a 75 gradi
• Il LED verde è rimasto due secondi ogni 10: LED di attività
• Led spento per due secondi: indica un accesso in scrittura sul dispositivo USB. Questo è importante da sapere, perché non dovremmo rimuovere il dispositivo USB quando in funzione.

Changelog

Riassunto delle Flag supportate

• boot_on: abilita il lavoro di base prima del carico vsh.self (come su MiralaTijera)
• boot_off: rende il core in grado di lavorare in background con vsh.self.
• install: installa i file necessari prima che venga caricato il file vsh.self (più sicuro).
• install2: procede all’installazione dei file in un secondo momento con vsh.self.
• removesm: elimina il file sm.self dalla directory dev_flash.
• ignoresm: ignora il caricamento del file sm.self ( può essere utile come test, in caso di crash, nel caso il system manager provochi un qualche danno, il file in ogni caso non verrà eliminato).
• verbose: attiva il registro completo.

Nota: Potrete scegliere di utilizzare il system manager anche esternamente, per fare questo rinominate il file “sm.self” come “sm_external.self” e copiatelo nella root della vostra pendrive.

Download: System Manager new 4.70