Avisos

ROMs y desarrollo Samsung Galaxy S II ROMs y desarrollo Samsung Galaxy S II

Respuesta
 
Herramientas
  #1  
Viejo 11/07/12, 11:11:29
Array

[xs_avatar]
thorazine74 thorazine74 no está en línea
Miembro del foro
 
Fecha de registro: mar 2010
Mensajes: 358
Modelo de smartphone: Samsung Galaxy S2
Tu operador: Vodafone
Info & Discusion sobre el HardBrick de los kernel Samsung Stock XXLQ5 / XWLPM / XWLPO (4.0.4)

Como parece que este es un tema caliente he decidido hacer esta pequeña recopilacion de informacion de lo que me queda claro sobre el tema de los nuevos bricks que estan produciendo con las nuevas ROM 4.0.4. Son las conclusiones a las que he llegado yo, si veis que algo no esta correcto o os parece discutible lo añadire al post, con la intencion de que la gente lo tenga lo mas claro posible a la hora de flashear las nueva ROM y evitar visitas al SAT.

De que bricks estamos hablando?


Propiamente dicho estaríamos hablando de 2 clases de bricks:

SuperHardBrick: despues de hacer un wipe/format, restaurar un backup con nandroid o instalar una ROM en formato ZIP desde el recovery, el telefono se queda colgado o se apagas solo y despues de esto no enciende de ninguna de las maneras, ni arrancando normalmente, ni en recovery ni en download.
Para este brick no hay solucion conocida posible, ni siquiera mediante JTAG ni por supuesto con un JIG USB, unicamente envio al SAT.
En realidad parece ser que no es un daño de hardware a nivel fisico, se especula que podria arreglar haciendo una especie de "low-level format" a la memoria completa pero a dia de hoy no hay software para hacer esto, de hecho parece ser que ni el SAT de Samsung hace esto, simplemente cambian la placa base y punto.

SemiHardBrick: despues de hacer un wipe/format, restaurar un backup con nandroid o instalar una ROM en formato ZIP desde el recovery, el teléfono se cuelga o se apaga, pero cuando reiniciamos puede acceder al modo download, pero ocurren errores al flashear algunas de las particiones, bien sea con Odin, MobileOdin, Heimdall, KIES, CWM, etc.
El brick seria el mismo pero en este caso los errores no habrian afectado a las areas de la memoria necesarias para que el telefono arranque en modo download (bootloader y sbl), sino que alguna de las particiones de sistema o datos tiene sectores dañados que hacen que el telefono se cuelgue al acceder ellos, tanto en lectura (usando el telefono) como escritura (flasheando la particion de sistema).
El daño es el mismo, lo sectores defectuosos no pueden ser recuperados o remapeados con ningun software conocido ni siquiera por Samsung, si se envia el telefono al SAT con este problema lo mas probable es que tambien cambien la placa base...
Si bien los sectores dañados no se pueden recuperar de ninguna forma conocida, lo que se puede hacer en este caso es reparticionar la memoria del telefono de forma que se muevan fisicamente de sitio en la memoria la localizacion de las particiones de forma que, a costa de reducir el tamaño de otras particiones, evitemos aquellas zonas con sectores dañados. Esto solo seria una solucion de compromiso para aquellos que necesitan usar el telefono o no pueden llevarlo al SAT. (Fuente: XDA)


Que factores influyen para que pueda suceder estos bricks:

1) El chip o el firmware del chip de memoria del telefono:
algunas revisiones de chips y/o firmwares del chip mmc parece ser que tienen un defecto de fabricacion o incorporan un firmware que no es compatible con una funcion del kernel Linux llamada MMC_CAP_ERASE que se usa al borrar/formatear las particiones de la memoria interna en modo seguro.
Con la aplicacion GotBrickBug de ChainFire (XDA) se puede comprobar si nuestro telefono tiene alguno de los chips conocidos como defectuosos.
Tambien con el programa eMMC Brickbug Check (Market)
NOTA: en general los programas estos funcionan detectando los ids de los chipse que se conoce hasta ahora que tiene el defecto, es decir que no pueden asegurar al 100% que tengamos un chip que NO lo tiene, de ahi que la app de ChainFire simplemente diga "Unknown" cuando NO tenemos un chip entre los conocidos como defectuosos.

2) El kernel: algunos kernels habilitan estan funcion, otros no. La diferencia entre tener este flag habilitado o no es como se hace el borrado de particiones, si no esta habilitado las particiones no se borran "a fondo" pero NO corremos riesgo de brick, si esta habilitado las particiones se borran en modo seguro pero SI nos arriesgamos a tener un brick.

Que kernels tienen el flag actiivado y por lo tanto son peligrosos':
Los kernels Stock Samsung 4.0.4 conocidos hasta el momento:
PDA: I9100XXLQ5 / Kernel: 3.0.15-I9100XXLQ5-CL753921 se.infra@SEP-85 #3
PDA: I9100XWLPM / Kernel:
3.0.15-I9100XWLPM-CL837163 dpi@DELL145 #3
PDA: I9100XWLPO / Kernel: ?

Siyah v3.1rc6: una version antigua que no deberia ser facil de encontrar. Cualquier otra version de Siyah se considera segura.


Se considera que todos los kernels stock Samsung 4.0.3 y anteriores serian seguros por no tener el flag habilitado
Asi mismo todos los kernels custom (realizados por desabolladores independientes) actuales deshabilitan esta funcion al compilar el kernel y por lo tanto serian tambien seguros (aunque en este caso no estaria de mas consultar al desarrollador del kernel en cuestion).

No hay forma que se sepa para comprobar si un kernel stock de Samsung tiene esta funcion habilitada si no se dispone del codigo fuente del kernel, como seria el caso de aquellas ultimas versiones de kernel stock Samsung para los que no ha publicado el codigo fuente todavia.
Por lo tanto en mi opinion, ya que hasta las versiones v4.0.3 todos los kernels Samsung stock eran seguros, y por algun motivo que solo ellos conocen han habilitado esta funcion en las nuevas ROM v4.0.4 (tanto en la XXLQ5, version leak, beta, no-oficial, como en la XWLPM, version oficial y publica), lo mas sensato seria considerar que, mientras no se demuestre lo contrario, todos los kernels 4.0.4 Samsung Stock podrian ser peligrosos.

3A) Wipes/Formats desde el Recovery hacer wipes/formats intenta borrar la particion antes de formatearla. Parece ser que hay la mayoria de las versions de recovery CWM estan afectadas. Aunque en principio el recovery stock que viene con los kernel oficiales de Samsung estaria parcheado para que no ejecutara esta funcion, ya hay informes de usuarios que parece sufrido bricks con el recovery stock.

3B) Restaurar un copia de seguridad Nandroid: al restaurar un backup nandroid normalmente borra la particion antes de restaurarla. Hacer el backup seria seguro, el brick estaria causado al restaurar un backup.

3C) Instalar un paquete en formato ZIP (una ROM, un parche, cualquier cosa) desde el Recoverty: si el paquete que estamos instalando contiene algun comando en el update-script que borra o formatea particiones (p.e. "format("ext4", "EMMC", "/dev/block/mmcblk0p9");) podriamos causar el brick si el update-binary que viene en el paquete ZIP intenta ejecutar el borrado de la particion. En este caso no lo tengo claro porque no hay versiones claras de los update-binary, pero por lo que se comenta en XDA aquellos que esten basados en Gingerbread serian seguro pero aquellos basados en IceCreamSandwich serian peligrosos.

Para que ocurra el brick es necesario que se den los 3 factores juntos 1 + 2 + 3A / 3B / 3C.
El factor determinante es el kernel, con un kernel seguro nunca tendremos el brick.
Sin embargo tener un kernel inseguro no es suficiente para tener el brick, deben juntarse con alguno de los otros factores.
Es decir p.e. si usamos un kernel que no tiene el MMC_CAP_ERASE habilitado estariamos seguros.
O si p.e. usamos un kernel stock Samsung 4.0.4 pero nunca hacemos wipes, nandroids, ni instalamos una ROM/Radio/Kernel en formato ZIP.
Tambien hay que recordar que tener un chip/firmware aparentemente seguro nunca significa 100% de seguridad en el caso de que se una con los otros 2 factores, digamos que tendriamos un riesgo menor.

Que se sepa hasta el momento flashear cualquier cosas desde Odin en modo Download seria seguro, porque en este caso nunca borramos las particiones, simplemente sobreescribimos la imagen encima, la unica excepcion seria tal vez si marcamos la opcion de "Repartition" en Odin, y probablemente en este caso ni siquiera estemos usando las funciones del kernel para esto, por lo que es bastante posible que en mi opinion tambien sea seguro.

Integracion kernel+recovery:

Como sabemos Samsung a diferencia de otros fabricantes integra el kernel y el recovery en la misma particion, es decir, no se puede flashear un recovery sin un kernel ni un kernel sin recovery, cuando se arranca desde el recovery no se arranca desde un kernel diferente, sino desde el mismo que cuando se arranca en modo normal. Esto hace que se puedan dar una serie de combinaciones peligrosas que puede que no este claras si no entendemos lo que estamos haciendo.

A) Kernel Stock + Recovery Stock: una ROM oficial al instalarse de partida contiene el kernel stock de Samsung + el recovery stock de Android (normalmente identificado como 3e). Aunque en principio parecia que era 100% seguro hacer wipes desde este recovery, empiezan a aparecer informes de gente que ha sufrido bricks haciendo wipes con el, por lo que deberian realizarse con precaucion. Se especula que Samsung ha modificado el recovery para evitar borrar las particiones en el modo que provoque el brick pero no esta claro si esto es efectivo o no. Ademas hay que tener en cuenta dos factores mas:
- El brick parece que ocurre cuando el controlador de la memoria se cuelga y corrompe una serie de estructuras del firmware, y este cuelgue no es algo que occurra el 100% de las veces, es un cuelgue que puede o no puede ocurrir, es posible hacer wipes sin que se cuelgue el controlador en varias ocasiones. Esto quiere decir que el hecho de que hayamos hecho un wipe y no hayamos tenido el brick no quiere decir que no vaya a suceder y estemos seguros.
- El recovery stock solo borra las particiones /data y /cache, por lo que un posible cuelgue del controlador de memoria al realizar estos wipes parece que es menos probable que afecte a otras particiones como el /kernel o el bootloader. Esto quiere decir que es menos probable que se produzca un SuperHardBrick desde el recovery stock que haciendo wipes de la particion /system de cwm (dado de que esta particion esta fisicamente en la memoria mas cerca del bootloader).
RESUMEN: no es recomendable hacer wipes desde el recovery stock sobre todo si se tiene un chip marcado como defectuoso

B) Kernel Stock + Recovery CWM temporal: con los metodos de root por recovery temporal o Fake CWM se puede cargar un CWM Recovery sin flashearlo, en este caso estamos corriendo el mismo kernel stock pero arrancando el recovery desde el ZIP que hacemos el "fake-flash", por lo aunque ejecutemos comandos como wipe o nandroid desde el CWM lo estamos haciendo sobre el kernel stock. Esta combinacion podria causar el brick mas facilmente siempre y cuando el recovery CWM temporal que estemos usando no este parcheando y este parece ser el caso de la mayoria de los que circulan actualmente.

RESUMEN: NUNCA SE DEBE DESDE ESTE Recovery CWM Temporal nada de esto:
- Wipes / Formats.
- Restaurar nandroid backups.
- Instalar ROMs, Kernels o cualquier otro ZIP que contenga comandos format en su update-script.


C) Kernel CF-Root o ChainFire + Recovery CWM: en este caso parece ser que el kernel es exactamente igual al stock, con la misma flag que causa el brick habilitada, dado que Chainfire no recompila los kernels, sino simplemente añade root, su, busybox y demas, aparte claro esta de sustituir el recovery stock por el CWM. Es decir tendriamos un kernel inseguro, pero para contrarrestar esto lo que parece ser que ha hecho Chainfire seria cambiar el codigo del recovery CWM que hace wipes para evitar invocar la funcion problematica.
Este kernel seria mas seguro que el stock dado que a pesar de tener un kernel inseguro estariamos relativamente protegidos por un recovery parcheado que ejecuta los wipes en un modo que invoca la funcion que causa el brick

CF-Root-SGS2_XX_OXA_LQ5-v5.6-CWM5

Fuente XDA

No existe kernel CF-Root para la LPM Rusa, sin embargo como las versiones de los kernels en las 2 ROMs son lo bastante parecidas es posible que el mismo CF-Root funcione en la LPM.

En el caso de que se compruebe que el parche de ChainFire en el CWM es efectivo este kernel seria mas seguro que el stock y dado que es exactamente igual a el en el tema de drivers de hardware no deberia causas problemas con camara, bluetooth, etc.
Sin embargo hay que tener en cuenta que instalar una ROM en formato ZIP desde este recovery que contenga el update-binary/update-script problematicos mencionados mas arriba si podria provocar el bug.

RESUMEN: no es recomendable instalar ROMs, Kernels o cualquier otro ZIP que contenga comandos format en su update-script desde el Recovery CWM del CF-Root LQ5

D) Otros kernel (Siyah, Fluxxi, etc.) + Recovery CWM: ninguno de estos kernels (excepto el muy antiguo Siyah v3.1rc6) tiene el MMC_CAP_ERASE flag habilitado por lo que todos los wipes formats que se ejecuten desde el recovery serian seguros. Sin embargo la mayoria o todos estos kernels no han sido actualizados para funcionar con las ROMs stock 4.0.4 de Samsung y parece ser que tienem varios bugs (Bluetooth, Camera Preview...).

Para soluciona esto se puede usar la ultima version de Siyah a la que se le han añadido los drivers bluetooth del Note con lo que se solucionan los posibles bugs:

SiyahKernel S2-v3.4.1
(USAR la version TAR para flashear por Odin en modo download, NO USAR la version ZIP desde un kernel 4.0.4 puesto que el update-script formatea la particion /cache)

Esto no solucionaria los bugs de la camara, para esto es necesario instalar unas librerias parcheadas que son validas para cualquier kernel no-stock

I9100-404-CameraFix-CustomKernels.zip
Estas librerias si se pueden instalar desde cualquier CWM ya que simplemente añaden una serie de archivos sin formatear nada.

O sea con la version esta de Siyah + estas librerias se podria mantener una de estas ROM 4.0.4 sin sufrir los bugs conocidos ni tener ningun peligro de brick, dado que desde el Recovery CWM de Siyah es posible hacer cualquier wipe, format, restaurar nandroid backups o instalar cualquier tipo de paquete ZIP.


Fuente: XDA

Actualizado: 2012/07/13 - Parece ser que el recovery stock no es 100% seguro...
Actualizado: 2012/07/17 - Reescrito varios parrafos ahora que tengo las cosas un poco mas claras, añadido el kernel CF-Root LQ5 con CWM Recovery parcheado y el parche de drivers para kernels non-stock
Actualizado: 2012/07/22 - Añadido el Siyah v3.4 parcheado y las librerias parcheadas para la camara para poder usar las ROMs 4.0.4 con un kernel completamente seguro.
Actualizado: 2012/07/25 - Añadido el kernel de la XWLPO

Última edición por thorazine74 Día 25/07/12 a las 13:38:02.
Responder Con Cita
Los siguientes 97 usuarios han agradecido a thorazine74 su comentario:
[ Mostrar/Ocultar listado de agradecimientos ]

HILOS_Honor

  #2  
Viejo 11/07/12, 11:31:51
Array

[xs_avatar]
lendark Hombre lendark no está en línea
Usuario muy activo
 
Fecha de registro: jul 2011
Mensajes: 1,037
Modelo de smartphone: Redmi 3s Pro
Tu operador: Vodafone
Gran tema que debe estar siempre arriba

Enviado desde mi GT-I9100 usando Tapatalk 2
Responder Con Cita
  #3  
Viejo 11/07/12, 11:47:13
Array

[xs_avatar]
XoF Hombre XoF no está en línea
Miembro del foro
 
Fecha de registro: jul 2009
Localización: Madrid
Mensajes: 479
Modelo de smartphone: LG G4
Tu operador: Jazztel
Genial!, hacía falta una recopilación de todo esto, porque había mucha gente preguntando todo el rato lo mismo.

Gracias thorazine74!!
Responder Con Cita
  #4  
Viejo 11/07/12, 12:08:52
Array

[xs_avatar]
ruben_limit ruben_limit no está en línea
Usuario muy activo
· Votos compra/venta: (2)
 
Fecha de registro: sep 2010
Mensajes: 1,726

Que hago si tengo una rom con el siyah maldito?? no estoy seguro al 100% ya que de ese kernel 3.1rc6 hubo dos versiones, uno que jodía y otro que no. De momento el móvil va bien, pero como cambio de kernel si al hacer el cambio se me va a joder? estoy condenado?
Responder Con Cita
  #5  
Viejo 11/07/12, 12:22:32
Array

[xs_avatar]
PEPO Hombre PEPO no está en línea
Colaborador/a
 
Fecha de registro: jul 2008
Localización: Terra Ferma
Mensajes: 2,661
Modelo de smartphone: HTC One Mini M4-Galaxy Tab 3 10"
Tu operador: Movistar
Aqui una posible solucion a los semi-bricks:http://www.samsunggalaxys.es/viewtopic.php?f=83&t=14528
Responder Con Cita
  #6  
Viejo 11/07/12, 12:28:13
Array

[xs_avatar]
koneX Hombre koneX no está en línea
Miembro del foro
· Votos compra/venta: (1)
 
Fecha de registro: ene 2012
Localización: Gasteiz
Mensajes: 107
Modelo de smartphone: Galaxy SII i9100
Tu operador: Orange
Gran artículo para aclarar dudas! Gracias!
Responder Con Cita
  #7  
Viejo 11/07/12, 12:31:24
Array

[xs_avatar]
joanhtchero Hombre joanhtchero no está en línea
Usuario muy activo
· Votos compra/venta: (4)
 
Fecha de registro: jun 2010
Localización: Barcelona
Mensajes: 3,803
Modelo de smartphone: Motorola G4 Plus
Tu operador: Vodafone
Gran aporte si señor. Poco a poco sabremos más y esperemos que se corrijan esos factores que dejan teléfonos como pisapapeles. Aún así, se necesitarán valientes!

Enviado desde mi GT-I9300 usando Tapatalk 2
__________________
Aprendiz de todo, maestro de nada. Aún así, si lo sé te lo explicaré.
Responder Con Cita
  #8  
Viejo 11/07/12, 12:56:27
Array

[xs_avatar]
thorazine74 thorazine74 no está en línea
Miembro del foro
 
Fecha de registro: mar 2010
Mensajes: 358
Modelo de smartphone: Samsung Galaxy S2
Tu operador: Vodafone
 Cita: Originalmente Escrito por ruben_limit Ver Mensaje
Que hago si tengo una rom con el siyah maldito?? no estoy seguro al 100% ya que de ese kernel 3.1rc6 hubo dos versiones, uno que jodía y otro que no. De momento el móvil va bien, pero como cambio de kernel si al hacer el cambio se me va a joder? estoy condenado?
En principio si flasheas un kernel nuevo, como una version actualizada de Siyah, en modo download, por Odin, no deberias tener ningun problema.

Sent from MyToasterOven using SmokeSignals
Responder Con Cita
  #9  
Viejo 11/07/12, 13:07:22
Array

[xs_avatar]
thorazine74 thorazine74 no está en línea
Miembro del foro
 
Fecha de registro: mar 2010
Mensajes: 358
Modelo de smartphone: Samsung Galaxy S2
Tu operador: Vodafone
 Cita: Originalmente Escrito por PEPO Ver Mensaje
Aqui una posible solucion a los semi-bricks:http://www.samsunggalaxys.es/viewtopic.php?f=83&t=14528
Es el mismo procedimiento que el link de XDA, es una posible solucion pero solo a ese caso concreto y no olvidemos que simplemente es una solucion super-radical que solo deberia ser el ultimisimo recurso para alguien que no puede mandar el telefono al SAT, porque flashear un pit editado a mano que mueve los offsets de las particiones y te reduce el espacio de la particion de UMS es algo que nadie deberia hacer a no ser que tenga muy claro lo que significa, por eso no lo he puesto en mas detalle, no vaya a ser que la gente se ponga a flashear pits caseros cuando tiene un simple soft-brick que no tiene nada que ver, y luego sea peor el remedio que la enfermedad...
Responder Con Cita
Gracias de parte de:
  #10  
Viejo 11/07/12, 13:17:46
Array

[xs_avatar]
joanhtchero Hombre joanhtchero no está en línea
Usuario muy activo
· Votos compra/venta: (4)
 
Fecha de registro: jun 2010
Localización: Barcelona
Mensajes: 3,803
Modelo de smartphone: Motorola G4 Plus
Tu operador: Vodafone
 Cita: Originalmente Escrito por ruben_limit Ver Mensaje
Que hago si tengo una rom con el siyah maldito?? no estoy seguro al 100% ya que de ese kernel 3.1rc6 hubo dos versiones, uno que jodía y otro que no. De momento el móvil va bien, pero como cambio de kernel si al hacer el cambio se me va a joder? estoy condenado?
Pues cambiarlo sin hacer wipes, es decir por Odin.

Enviado desde mi GT-I9300 usando Tapatalk 2
__________________
Aprendiz de todo, maestro de nada. Aún así, si lo sé te lo explicaré.
Responder Con Cita
  #11  
Viejo 11/07/12, 13:35:07
Array

[xs_avatar]
ruben_limit ruben_limit no está en línea
Usuario muy activo
· Votos compra/venta: (2)
 
Fecha de registro: sep 2010
Mensajes: 1,726

Por odin no hace wipes seguro?
Responder Con Cita
  #12  
Viejo 11/07/12, 17:27:22
Array

[xs_avatar]
joanhtchero Hombre joanhtchero no está en línea
Usuario muy activo
· Votos compra/venta: (4)
 
Fecha de registro: jun 2010
Localización: Barcelona
Mensajes: 3,803
Modelo de smartphone: Motorola G4 Plus
Tu operador: Vodafone
 Cita: Originalmente Escrito por ruben_limit Ver Mensaje
Por odin no hace wipes seguro?
que se sepa flashear cosas desde Odin en modo Download seria seguro en este caso, porque en este caso nunca borramos las particiones, simplemente sobreescribimos la imagen encima, y probablemente en este caso no estamos usando las funciones del kernel para esto.
__________________
Aprendiz de todo, maestro de nada. Aún así, si lo sé te lo explicaré.
Responder Con Cita
Gracias de parte de:
  #13  
Viejo 11/07/12, 17:31:13
Array

[xs_avatar]
YossYGalaxy YossYGalaxy no está en línea
Usuario muy activo
 
Fecha de registro: jun 2011
Localización: Asturias Patria Querida
Mensajes: 2,068
Modelo de smartphone: Samsung Galaxy SII
Tu operador: Yoigo
Muy bueno. Aportando datos fundamentados y con una gran cordura. Gracias!
Responder Con Cita
  #14  
Viejo 11/07/12, 17:43:16
Array

[xs_avatar]
chatrat Hombre chatrat no está en línea
Miembro del foro
 
Fecha de registro: dic 2009
Localización: Argentina
Mensajes: 418
Modelo de smartphone: SGSIII
Tu operador: Movistar
Perdon si esta esto repetido, pero como se puede explicar que las ultimas dos actualizaciones o (leaks) de samsung, en este caso la version 4.0.4 traigan en su kernel la funcion MMC_CAP_ERASE.

No estan al tanto de nada d elo que es expone thorazine74 en este hilo??? Ya tienes trabajo de CEO en Samsung si no se han enterado!...

saludos, y lamentablemente solo despierta ideacion paranoide acerca de esta actitud de samsung.
__________________

Responder Con Cita
  #15  
Viejo 11/07/12, 20:18:25
Array

[xs_avatar]
angelitoo10 Hombre angelitoo10 no está en línea
Miembro del foro
 
Fecha de registro: jun 2011
Localización: Málaga
Mensajes: 174
Modelo de smartphone: Samsung Galaxy S7 Edge
Tu operador: Movistar
Muy uen aporte. Aclara muchas de las cosas que están pasando ahora y que que nos rondan a todos por la cabeza y aporta cosas que por lo menos yo no sabía.

Gracias
Responder Con Cita
  #16  
Viejo 11/07/12, 22:21:23
Array

[xs_avatar]
XoF Hombre XoF no está en línea
Miembro del foro
 
Fecha de registro: jul 2009
Localización: Madrid
Mensajes: 479
Modelo de smartphone: LG G4
Tu operador: Jazztel
 Cita: Originalmente Escrito por chatrat Ver Mensaje
Perdon si esta esto repetido, pero como se puede explicar que las ultimas dos actualizaciones o (leaks) de samsung, en este caso la version 4.0.4 traigan en su kernel la funcion MMC_CAP_ERASE.

No estan al tanto de nada d elo que es expone thorazine74 en este hilo??? Ya tienes trabajo de CEO en Samsung si no se han enterado!...

saludos, y lamentablemente solo despierta ideacion paranoide acerca de esta actitud de samsung.
Yo no quisiera pensar mal, pero el fallo puede haber ocurrido simplemente porque hayan recompilado un kernel desde cero para mejorar el rendimiento en las versiones 4.0.4, y esa opción se haya quedado activada (porque venga activada por defecto).
Otra opción es pensar mal y hayan dicho, "vamos a fomentar que unos pocos con sgs2 se vayan al sgs3". Pero en mi opinión eso sería una estrategia peligrosa, ya que la gente que suele utilizar recoveries, rooteos, y roms extraoficiales se suelen informar, y si se enteran de que el fallo ha sido intencionado... se pasarían a la competencia. Al menos yo lo haría.
Sobre las dos versiones, creo que a nivel de kernel es la misma compilación. De esto no tengo datos, a ver si veo algo en xda.
Responder Con Cita
Gracias de parte de:
  #17  
Viejo 13/07/12, 01:41:27
Array

[xs_avatar]
thorazine74 thorazine74 no está en línea
Miembro del foro
 
Fecha de registro: mar 2010
Mensajes: 358
Modelo de smartphone: Samsung Galaxy S2
Tu operador: Vodafone
Sobre la funcion esa que han habilitado parece ser que se trata de un borrado mas "completo", por temas de privacidad, seria algo asi como borrar todos los bloques de la particion uno por uno, mientras que antes simplemente se formateaba la particion. Seria algo asi como la diferencia entre el formato rapido y el formato completo, o entre formatear una particion y escribir ceros sobre ella.
La funcion en si es util por temas de privacidad, te aseguras de que no es posible (o facil) recuperar los datos de un telefono que vayas a vender, en el caso de que tengas cosas sensibles en el. El problema esta en que Samsung parece no importarle si todos los Galaxy soportan esa funcion o no...
Sobre las teorias conspiratorias no se que decirte, parece ser que Samsung estaba trabajando para solucionar este problema con los Note, si ahora se reproduce en el Galaxy prefiero pensar que simplemente el equipo de ingenieros de uno y otro telefonos no se hablan...
Responder Con Cita
  #18  
Viejo 13/07/12, 22:04:33
Array

[xs_avatar]
XoF Hombre XoF no está en línea
Miembro del foro
 
Fecha de registro: jul 2009
Localización: Madrid
Mensajes: 479
Modelo de smartphone: LG G4
Tu operador: Jazztel
 Cita: Originalmente Escrito por thorazine74 Ver Mensaje
Sobre la funcion esa que han habilitado parece ser que se trata de un borrado mas "completo", por temas de privacidad, seria algo asi como borrar todos los bloques de la particion uno por uno, mientras que antes simplemente se formateaba la particion. Seria algo asi como la diferencia entre el formato rapido y el formato completo, o entre formatear una particion y escribir ceros sobre ella.
La funcion en si es util por temas de privacidad, te aseguras de que no es posible (o facil) recuperar los datos de un telefono que vayas a vender, en el caso de que tengas cosas sensibles en el. El problema esta en que Samsung parece no importarle si todos los Galaxy soportan esa funcion o no...
Sobre las teorias conspiratorias no se que decirte, parece ser que Samsung estaba trabajando para solucionar este problema con los Note, si ahora se reproduce en el Galaxy prefiero pensar que simplemente el equipo de ingenieros de uno y otro telefonos no se hablan...
Tuve un problema parecido en el trabajo (curro en temas de SW empotrado). Hay una protección en el kernel para evitar un borrado de la memoria flash, para los casos en los que el boot esté almacenado en esta. Esta protección no es más que un flag en el kernel para que no borre la partición/zona del boot en la flash. En nuestro caso no existía una protección por HW.
No se si es lo mismo que ocurre con el flag MMC_CAP_ERASE, pero pinta a algo parecido. Algunos SGS2 tiene la protección por HW y otros (imagino que los primeros que se vendieran) no la tienen, de ahí el problema de hacer un SW compatible con ambos (esto es suposición mía). Además hay que añadir los problema que no sabemos, derivados de ese flag.
Como he dicho antes, no quiero pensar mal, porque sería una mala imagen para Samsung.
Responder Con Cita
  #19  
Viejo 17/07/12, 00:18:58
Array

[xs_avatar]
thorazine74 thorazine74 no está en línea
Miembro del foro
 
Fecha de registro: mar 2010
Mensajes: 358
Modelo de smartphone: Samsung Galaxy S2
Tu operador: Vodafone
Desconozco si ese es el problema pero si una simple app como el GotBrickBug puede identificar el id y la revision de firmware del chip que llleva cada telefono no creo que Samsung lo tenga muy dificil para hacer dos cases en el codigo del kernel con y sin MMC_CAP_ERASE.
Y si no simplemente deshabilitarla del todo como estaba antes del 4.0.4 que por muy preferible que sea esa forma de borrado creo que todos preferimos un telefono no brickeado...
Responder Con Cita
  #20  
Viejo 19/07/12, 11:17:48
Array

[xs_avatar]
matovi matovi no está en línea
Miembro del foro
 
Fecha de registro: sep 2009
Mensajes: 310
Modelo de smartphone: Galaxy SII

thorazine74
Con la aplicacion GotBrickBug de ChainFire (XDA) se puede comprobar si nuestro telefono tiene alguno de los chips conocidos como defectuosos.
Tambien con el programa eMMC Brickbug Check (Market)
NOTA: en general los programas estos funcionan detectando los ids de los chipse que se conoce hasta ahora que tiene el defecto, es decir que no pueden asegurar al 100% que tengamos un chip que NO lo tiene, de ahi que la app de ChainFire simplemente diga "Unknown" cuando NO tenemos un chip entre los conocidos como defectuosos.



Que kernels tienen el flag actiivado y por lo tanto son peligrosos':
Los kernels Stock Samsung 4.0.4 conocidos hasta el momento:
PDA: I9100XXLQ5 / Kernel: 3.0.15-I9100XXLQ5-CL753921 se.infra@SEP-85 #3
PDA: I9100XWLPM / Kernel: 3.0.15-I9100XWLPM-CL837163 dpi@DELL145 #3

Siyah v3.1rc6: una version antigua que no deberia ser facil de encontrar. Cualquier otra version de Siyah se considera segura.

Fuente: XDA

Actualizado: 2012/07/13 - Parece ser que el recovery stock no es 100% seguro...
Actualizado: 2012/07/17 - Reescrito varios parrafos ahora que tengo las cosas un poco mas claras, añadido el kernel CF-Root LQ5 con CWM Recovery parcheado y el parche de drivers para kernels non-stock[/quote]

Ademas de darte las gracias, he de felicitarte por el magnifico articulo que has posteado, ademas de ser claro y conciso.

Última edición por matovi Día 19/07/12 a las 11:28:31.
Responder Con Cita
Respuesta

Estás aquí
Regresar   Portal | Indice > Zona Samsung > Samsung Galaxy S II > ROMs y desarrollo Samsung Galaxy S II

Herramientas


Hora actual: 15:31:55 (GMT +2)



User Alert System provided by Advanced User Tagging (Lite) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.