Nelle settimane scorse sono state rilasciate le ROM ICS 4.0.3/4.0.4 per il Galaxy Note ed il Galaxy S2; in questa sede non voglio, per l’ennesima volta, scatenare una discussione sulla pessima, almeno per il nostro paese, gestione degli aggiornamenti da parte di Samsung ma cercare di chiarire il pericolosissimo problema del brick che queste ROM possono creare in determinate situazioni. Cercheremo di capire il motivo, le cause e cosa si può fare per tenersi lontani dal rischio. Il tutto dopo il break, seguitemi ma prima lasciatemi ringraziare il nostro utente Andrea per averci segnalato la notizia.

Il problema sembra riguardare soltanto i dispositivi equipaggiati con processore proprietario Samsung, il famoso Exynos; alcuni di questi presentano un problema della memoria flash che, per un difetto, potrebbe essere bloccata in alcune partizioni e quindi inutilizzabile. La maggior parte delle volte il problema si presenta sulla /data partition ma possono esserci problemi anche sulla /cache/system oltre che sul kernel (più raramente, per fortuna). Il brick è definitivo e non può essere risolto se non con la ssostituzione della scheda madre: http://www.batista70phone.net/attenzione-galaxy-note-al-kernel-cf-root-lpy-e-alle-cooked-contenenti-questo-kernel-possibile-brick-t23224.html

La prima cosa da fare è scaricare questo APK di Chainfire che vi dirà immediatamente se il vostro GS2/Note è vulnerabile (ho appena scoperto che il mio lo è); per fortuna esistono sempre delle soluzioni alternative in caso di responso negativo, vediamo quali.

Il problema sembra essere più frequente sui dispositivi “non root” per cui questi utenti dovranno prestare molta attenzione; gli utenti con dispositivi “rooted” agiranno a loro rischio e pericolo. Quali sono le cause del Brick?

  1. Chip/frew eMMC difettoso: non è in grado di eseguire il “Command 38” che provvede al data reset e quindi causa il brick. Una variante di questo chip potrebbe essere presente su alcuni Kindle Fire.
  2. Binary recovery ICS addetta al tentativo di reset al momento della formattazione; il problema non esiste con le binary recovery GingerBread che non procedono alla cancellazione dei dati. Ovviamente . se questi kernel sono inclusi nello .zip della ROM potranno causare il problema.
  3. Qualunque kernel che “autorizza” il data reset; per gli addetti ai lavori esiste la possibilità di rendere un kernel sicuro cancellando la MMC_CAP_ERASE dal percorso drivers/mmc/mshci.c

Se ne deduce che, almeno per i Galaxy S2, partendo da kernel sicuri (cliccando sul link a fondo articolo troverete la lista siduri/insicuri) non ci sono problemi in quanto non autorizzano il data reset; sugli stessi dispositivi, però, potrebbero crearsi dei brick a causa del binary recovery di alcune ROM. Molto più preoccupante la situazione per i Galaxy Note: bisogna essere assolutamente sicuri del kernel on board che dovrà essere uno di quelli classificati come Safe.

Letta così la situazione sembrerebbe senza via d’uscita ma la community degli sviluppatori sta lavorando duramente (molto più di quanto non sembri fare direttamente Samsung) per rendere le operazioni di aggiornamento ragionevolmente sicure.

Chiedo da subito scusa se ci dovessero essere cose non molto chiare ma io, purtroppo, non sono un tecnico e la traduzione dall’inglese potrebbe non essere stata perfetta. Sono sicuro che quando tornerà dalla sua meritata settimana di vacanza, il nostro Mik potrà essere molto più chiaro di quanto non lo sia stato io. Per chi ha dimestichezza con l’argomento e se la cava con l’inglese i link di seguito potranno essere di aiuto per avere le idee ancora più chiare.

Link 1  Link 2    Link 3    Link 4

Shares:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *