Posible solucion a los brickeos

cpro · #**121** 02/08/13, 21:18:22

Cita: Originalmente Escrito por beachsun

utsetbacklight 1
uttext 20 30 "********************************************* **"
uttext 20 40 "* PROBAAAAAAANNNNNNNDDDDDOOOOOOOOO"
uttext 20 50 "********************************************* **"
uttext 20 60 " "

Recordar hacer el mkimage, y rellenar con 0s hasta 65535 bytes.

Si me permites una modificación a tu buena idea... que sólo lo añadan, que no cambien nada. No sea que el utscript se utilice en la siguiente actualización, en lugar de la que esté en curso y entonces sí tienen un brick total.

beachsun · #**122** 02/08/13, 21:26:19

No me gusta lo que hace el 1st, lo primero es un erase boot...

Cre o que mejor que una vez probado restituyan el 1st...

**STEVE_MARS** · #**123** 02/08/13, 21:26:41

Cita: Originalmente Escrito por beachsun

Una pregunta muuuy tonta...
Si arrancas la tablet (Pow) con una mSD con una particion normal Fat/fat32 y los ficheros del update del firmware copiados en raiz, arranca totalmente normal, verdad?

Si no lo sabeis, antes de probarlo, cambiar el utscript_1st por uno modificado por vosotros que no haga nada mas que pintar en la pantalla...
Algo así como

utsetbacklight 1
uttext 20 30 "********************************************* **"
uttext 20 40 "* PROBAAAAAAANNNNNNNDDDDDOOOOOOOOO"
uttext 20 50 "********************************************* **"
uttext 20 60 " "

Recordar hacer el mkimage, y rellenar con 0s hasta 65535 bytes.

No hace nada, solo arranca en la SD si pulsas power y vol-, y si encuentra el utscript lo ejecuta.
¿Y si ponemos la SD de recuperacion en un utscript? No creo que se pueda porque el formato no es compatible (jejeje soy Anthony Hopkins en Psicosis, me pregunto y me respondo).
Pero si encontraramos la forma de crear un utscript con los binaros directamente, ¿posiblemente volveriamos a escribir el bootloader de las tablets brickeadas?

cpro · #**124** 02/08/13, 21:30:49

Es que a mi me da por pensar que el 1st, el que borra, es el primero que hicieron y por eso cambiaron al otro pero... en "bootloader_sd.vhd" aparecen ambos.
¿Un desensamblador y un manual de la arquitectura ARM?

De todos modos, se pueden poner mensajes diferentes a ver cuál ejecuta, aunque yo creo que siempre es utscrip.

**STEVE_MARS** · #**125** 02/08/13, 21:33:46

Cita: Originalmente Escrito por cpro

Es que a mi me da por pensar que el 1st, el que borra, es el primero que hicieron y por eso cambiaron al otro pero... en "bootloader_sd.vhd" aparecen ambos.
¿Un desensamblador y un manual de la arquitectura ARM?

De todos modos, se pueden poner mensajes diferentes a ver cuál ejecuta, aunque yo creo que siempre es utscrip.

http://infocenter.arm.com/help/index.jsp

Aqui tienes toda la documentacion de ARM.

**STEVE_MARS** · #**126** 02/08/13, 21:34:40

Cita: Originalmente Escrito por cpro

Es que a mi me da por pensar que el 1st, el que borra, es el primero que hicieron y por eso cambiaron al otro pero... en "bootloader_sd.vhd" aparecen ambos.
¿Un desensamblador y un manual de la arquitectura ARM?

De todos modos, se pueden poner mensajes diferentes a ver cuál ejecuta, aunque yo creo que siempre es utscrip.

El cocinero de la Hyunday T7s solo modifica el utscript, me lo dijo ayer.

Sp4ceM4rine · #**127** 02/08/13, 21:42:52

Cita: Originalmente Escrito por cpro

Hi, you are wellcome.

Sorry for my English. I have been reading you at slatedroid. I think problem is: partitions increase their size but you are copying a smaller disk image with no change on FileSytem information.

As I am not sure about your skills on UNIX/Linux I have added some code. Try to do this:

First, create a file of the desired size using dd
Código:
```
dd if=/dev/zero of=newuser.raw bs=1M count=2048
```
Previous command creates a file that contains 2048MB = 2GB (showed in File system as 2.1GB) zeros
Format it using ext4
Código:
```
mkfs.ext4 newuser.raw
```
It will warning you about it is not a block device. Continue.
Mount it on your system. For example, creating a directory "new" and executing
Código:
```
mkdir new
sudo mount -o loop -t ext4 newuser.raw new
```
Now, unpack userdata.img, mount it at an "old" diretory and copy its contents in the new created image disk.
Código:
```
sudo mount -o loop -t ext4 userdata.raw old
cp -a old/. new/.
```
Unmount "new", pack "newuser.raw" to "userdata.img"

Now, I hope you can use it with your modified utscript for "0 512 2048 500".

Espero que no haya problemas por escribirlo en inglés: le digo sólo que cree primero una imagen de 2GB porque si copia en una partición (aunque sea de 2GB) una imagen de 1GB el sistema de archivos le va a mostrar que es de 1GB o eso creo, que es el problema que ha dicho que tiene en el otro foro.

Dont worry about your english, french is my first language and I'm often struggling to speak or write in a decent english. I really appreciate your suggestion. It makes sense to use a 2Go image. I'll give it a try as soon as I can. Thanks again.

beachsun · #**128** 02/08/13, 22:04:29

Cita: Originalmente Escrito por STEVE_MARS

No hace nada, solo arranca en la SD si pulsas power y vol-, y si encuentra el utscript lo ejecuta.
¿Y si ponemos la SD de recuperacion en un utscript? No creo que se pueda porque el formato no es compatible (jejeje soy Anthony Hopkins en Psicosis, me pregunto y me respondo).
Pero si encontraramos la forma de crear un utscript con los binaros directamente, ¿posiblemente volveriamos a escribir el bootloader de las tablets brickeadas?

Si las brickedas pueden ejecutar el utscript al encender con (-)(Pow), supongo que no estarian brikeadas, sino que se podria haber actualizado la tablet, o al meno hubieran visto por pantalla el inicio de la actulizacion, no?

beachsun · #**129** 02/08/13, 23:57:17

El objetivo de la prueba del utscript_1st, era que al estar utscript dos veces(realmente una utscript y otra utscript_1st) en bootloader_sd.vhd, tal y como comenta cpro, y sabiendo que arrancar con (-)(pow) lanza utscript, ver si sin pulsar nada lanzaba utscript_1st, pero pensandolo bien hubiera sido un suicidio si alguien se olvida la sd con los ficheros y arranca la tablet... se hubiera actualizado sola...
Puede haber una combinacion que lo lanze? el famoso (+)(-)(Pow)?
Y el reset?? se sabe que hace el reset? quizas el encender con el reset lanza utscript_1st que, como hemos visto, hace un borrado del boot antes de instalar...

Aqui la primera aparicion de utscript :

Código:

bootcmd 
movi r k 0 40008000;movi r covery 0 40d00000 300000;bootm 40008000 40d00000 
mmc rescan 1;fatload mmc 1 40000000 utscript;source 40000000;movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 41000000

Aqui la segunda :

Código:

bootargs= 
bootcmd=mmc rescan 1;fatload mmc 1 40000000 utscript_1st;source 40000000; movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 41000000
bootdelay=1 
baudrate=115200 
ethaddr=00:40:5c:26:0a:5b
ipaddr=192.168.0.20
serverip=192.168.0.10 
gatewayip=192.168.0.1 
netmask=255.255.255.0 
rootfslen= 100000

Las dos hacen lo mismo con el script utscript[_1st] :
Lo cargan en al posicion 40000000, lo ejecutan desde alli y despues leen el kernel, el rootfs y lo arracan...

beachsun · #**130** 03/08/13, 00:44:39

El tema del TrustZone despejado :
http://en.wikipedia.org/wiki/ARM_arc...28TrustZone.29

Security Extensions (TrustZone)

The Security Extensions, marketed as TrustZone Technology, is found in ARMv6KZ and later application profile architectures. It provides a low cost alternative to adding an additional dedicated security core to an SoC, by providing two virtual processors backed by hardware based access control. This enables the application core to switch between two states, referred to as worlds (to reduce confusion with other names for capability domains), in order to prevent information from leaking from the more trusted world to the less trusted world. This world switch is generally orthogonal to all other capabilities of the processor, thus each world can operate independently of the other while using the same core. Memory and peripherals are then made aware of the operating world of the core and may use this to provide access control to secrets and code on the device.
Typical applications of TrustZone Technology are to run a rich operating system in the less trusted world, and smaller security-specialized code in the more trusted world (named TrustZone Software, a TrustZone optimised version of the Trusted Foundations Software developed by Trusted Logic Mobility), allowing much tighter digital rights management for controlling the use of media on ARM-based devices, and preventing any unapproved use of the device. Trusted Foundations Software was acquired by Gemalto. Giesecke & Devrient developed a rival implementation named Mobicore. In April 2012 ARM Gemalto and Giesecke & Devrient combined their Trustzone portfolios into a joint venture Trustonic. Open Virtualization is an open source implementation of the trusted world architecture for TrustZone.
In practice, since the specific implementation details of TrustZone are proprietary and have not been publicly disclosed for review, it is unclear what level of assurance is provided for a given threat model.

**STEVE_MARS** · #**131** 03/08/13, 07:41:19

He estado revisando la forma de arrancar para instalar el recovery que namko compilo para otros tablets de urbetter y el utscript hace esto:

Código:

setenv bootargs root=/dev/ram0 init=/init console=ttySAC0,115200
bootm 20008000
uttext 20 20 "Failed. Please check the recovery."
sleep 10
reset

En la SD debe estar este utscript y el recovery, ¿os aporta algo nuevo?

**STEVE_MARS** · #**132** 03/08/13, 08:04:12

Respuesta de josemacl al tema de los utscript:

"Sólo mira el utscript_all. De hecho en el último repack que he hecho los he quitado y se flashea todo sin problemas."

**STEVE_MARS** · #**133** 03/08/13, 08:54:14

Y leed este post, a ver que opinais:
http://www.htcmania.com/showthread.p...51#post7782151

**STEVE_MARS** · #**134** 03/08/13, 08:56:03

Y en ultimo extremo este:
http://www.htcmania.com/showthread.php?t=240886

cpro · #**135** 03/08/13, 12:02:09

Cita: Originalmente Escrito por STEVE_MARS

He estado revisando la forma de arrancar para instalar el recovery que namko compilo para otros tablets de urbetter y el utscript hace esto:

Código:

setenv bootargs root=/dev/ram0 init=/init console=ttySAC0,115200
bootm 20008000
uttext 20 20 "Failed. Please check the recovery."
sleep 10
reset

En la SD debe estar este utscript y el recovery, ¿os aporta algo nuevo?

El archivo utsript original, al final (enlazo con lo que puso teredur), contiene esto:

Código:

utsetbacklight 0
shut 1
reset

sleep 1000


fatload mmc 1 40008000 zImage.debug
setenv bootargs root=/dev/ram0 init=/init console=ttySAC2,115200
utsetbacklight 0
bootm 40008000
uttext  20 200 "Failed. Please check the recovery zImage.debug."
sleep 10
reset

sleep 500
uttext  20 210 "Reboot..."
sleep 2000

utsetbacklight 0
shut 1
reset

Me falta la carga del zImage.debug

En cuanto a los otros, si no he entendido mal, como llevaban una mSD como memoria NAND, la extraian para formatearla, precisamente, porque no arrancaban desde el lector de tarjetas (que no sé si se podría o no) pero... ¿como sacamos nosotros la eMMC y la formateamos en el ordenador? Si lo he entendido mal y es otra cosa, prometo volver a leerlo.

Edito: Uno sí que lo hace con la interna pero el primero lo hace con una tarjeta externa y un firm de otro equipo, me parece. Aunque, tal cual estamos ahora, esto habría que mandárselo a Spemall para que lo pruebe él.

cpro · #**136** 04/08/13, 16:09:38

He estado intentando ordenar lo que sabemos y lo que no, que me pierdo un poco si no, para que lo miréis y digáis si hay algo erróneo (que además, yo no tengo ni idea de android e igual estoy poniendo tonterías). La idea, si lo creéis -en realidad, tú, STEVE- apropiado, sería meterlo en el primer mensaje (o abrir un hilo para ir actualizando esto conforme se descubran cosas).

No arranca desde el lector de tarjetas pero sí entra en modo "u-boot":creemos entender que al encender manteniendo pulsado el botón Vol- y una mSD en el lector, se intenta ejecutar un fichero llamado "utscript".

El firm del dispositivo incorpora 13 archivos: una imagen de un cargador (bootloader_sd.vhd), imagenes de disco de sistema y usuario (datos y aplicaciones), configuración (set_bootargs), cuatro archivos utscript, un ramdisk u-boot y un archivo "misc" (que contiene información de configuración y de utscript).

Según "utscript", sabemos que el cargador se copia en la eMMC quitando el primer bloque (512B) que contiene el MBR o tabla de particiones y por su tamaño, contine todo lo necesario para arrancar el sistema pero, ¿sobreescribe "misc" al cargador o se copia en otro punto de la eMMC? Si de una versión del firm a la siguiente no cambia, no sería necesario copiar ninguno de los archivos (siempre y cuando se esté instalando sobre la versión anterior).
El núcleo zImage y el ramdisk se copian, respectivamente, en las áreas de kernel y ramdisk, cuyas direcciones desconocemos. A priori, cada nuevo firm integrará unos nuevos ficheros.
El ramdisk con u-boot ¿es el "shell" que ejecuta los utscript?

Si no se borra el boot, tampoco se ven alteradas las particiones por lo que, si no se desean cambiar, no sería tampoco necesario ejecutar "fdisk".
Formatea las particiones de datos, sistema y usuario pero no la de cache: no es necesario limpiarla (hacer "wipe").

Sobre las particiones de sistema y usuario, una vez formateadas, copia la imagen. Probando a cambiar el tamaño de las particiones, se reduce el tamaño de la de datos pero las otras no cambian: si vuelca el sistema de archivos (desempaquetado) directamente, tampoco resulta necesario formatear.

Entre medias, ha copiado un archivo "ramdisk-recovery-uboot.img" pero, como ese fichero no está en el firm... no lo puede copiar. Desconocemos también la dirección de memoria del área "c", por lo que no sabemos si la eMMC puede tener esa zona con los datos de ese "recovery".
Al final del "utscript" carga un archivo "zImage.debug" (¿un núcleo con código de depuración?) y abre una consola. Ese código es muy parecido (cambian el nombre de la consola y la dirección de carga) al del "utscript" del recovery de namko. El cambio de dirección, seguramente, puede ser debido a la memoria que se reserva el kernel para sí: a partir de la misma pueden alojarse datos. Pero falta la línea de qué carga el código de namko.

Tenemos también el firm del Herotab que sigue el mismo esquema que este pero aquí si encontramos un archivo "recovery" u un archivo "zImage.debug". Curiosamente, aunque no son iguales, ambos tienen el mismo tamaño. ¿Es el recovery un kernel que incorpora una imagen de disco en ramdisk y se ejecuta autocontenido?

En el "utscript" sí aparecen las direcciones del kernel, etc., en lugar de poner áreas, pero imagino que son diferentes a las del A15.

Mirando en el repositorio de namko, me parece, hay que tener el código fuente del kernel para poderlo compilar. No disponemos del núcleo con el código específico de Voyo y usarlo tal cual, cuando menos, puede ser peligroso.

Mirando en la documentación de Android, hay tres tipos de configuración: "user", "userdebug" y "eng". Su uso es, respectivamente, producción, producción con acceso root y desarrollo. ¿Estará el kernel que incorpora hecho como "userdebug"?

cpro · #**137** 04/08/13, 16:17:56

Para probar qué hace al final, si es posible, sería interesante poner una tarjeta que contenga el archivo "zImage" renombrado a "zImage.debug", el "set_bootargs" y un utscript con el siguiente contenido:

Código:

fatload mmc 1 0x41000000 set_bootargs
source 0x41000000
utupdateenv
utsetbacklight 1
uttext  20 30 "**********************************************"
uttext  20 40 "  Probando zImage.debug "
uttext  20 50 "**********************************************"
uttext  20 60 "                                "

fatload mmc 1 40008000 zImage.debug
setenv bootargs root=/dev/ram0 init=/init console=ttySAC2,115200
bootm 40008000
uttext  20 100 "Failed. Please check the recovery zImage.debug."
sleep 15

utsetbacklight 0
shut 1
reset

No creo que hagan falta las tres primeras líneas, ni el "set_bootargs", que son para cargar las variables de entorno pero, tampoco está de más.

En teoría no puede romperse nada, que no escribe en la eMMC

beachsun · #**138** 04/08/13, 18:17:51

Cita: Originalmente Escrito por cpro

¿sobreescribe "misc" al cargador o se copia en otro punto de la eMMC?

Creo que sobreescribe parte del cargador... no veo nada que me indique que no sea así.
Quizas sea una manera de "cargar" distintos parametros sin rehacer de nuevo todo el fichero de BOOT, que puede ser delicado.

Cita: Originalmente Escrito por cpro

No arranca desde el lector de tarjetas pero sí entra en modo "u-boot":creemos entender que al encender manteniendo pulsado el botón Vol- y una mSD en el lector, se intenta ejecutar un fichero llamado "utscript".

Respecto al arranque tenemos muchas dudas :

Se puede forzar un BootSD? : entendiendo como tal que el arranque lo busque en la SD y no en la eMMC. De ser así se podrían recuperar las tablets con el Boot Corrupto. Lo que se me ha ocurrido esta mañana es que quizas no se haya implementado por soft(pulsaciones de teclas al arrancar) ni por hard(switches), como ultimo recurso nos quedaria intentarlo modificando el hard, en caso de que eMMC y SD sean identicas a nivel de señales, se podrian intercambiar las "pistas".

Siguiendo con el eMMCBoot : tenemos :
- Arranque normal : carga todo desde la eMMc
- Arranque "Upgrade" (-)(Pow): arranca desde eMMC, y su uboot busca si existe un fichero utscript en la mSD, de ser así lo ejecuta. La modificacion de este UtScript nos puede permitir :
  - Flashear "a la carta": P.Ej. evitando machacar el arranque
  - Arrancar Linux/Android desde la mSD : En lugar de flashear
  - Extraer informacion de la eMMC a la mSD

El fichero que arranca el update parece ser utscript, que es el que pinta en pantalla :
* Exynos5 upgrade JB2 V0.1[utscript]
Seria importante confirmar que realmente es este el fichero que se llama, o bien revisando que sale por pantalla al upgadear, o creando varios utscripts, cada uno poniendo un texto distinto algo como :

Código:

utsetbacklight 1
uttext  20 30 "**********************************************"
uttext  20 40 "* Exynos5 upgrade JB2 V0.1[utscript]"
uttext  20 50 "**********************************************"

Cambiando el Texto en negrita para saber cual se ha ejecutado.

Cita: Originalmente Escrito por cpro

Entre medias, ha copiado un archivo "ramdisk-recovery-uboot.img" pero, como ese fichero no está en el firm... no lo puede copiar. Desconocemos también la dirección de memoria del área "c", por lo que no sabemos si la eMMC puede tener esa zona con los datos de ese "recovery".

Esto me mieditooo, dependiendo de la gestion/control de errores del uboot.
Esta es la parte del script :

Código:

fatload mmc 1 0x40008000 ramdisk-recovery-uboot.img
movi w c 0 0x40008000 300000
uttext  20 160 "Done."

uttext  20 180 "Update system...Wait some minutes."

Como ha comentado cpro, el fichero que intenta cargar, en la posicion de memoria 0x40008000, no existe en la mSD, y por lo que parece no se aborta el script porque se flashean el resto de ficheros...
Por tanto sigue por la siguiente linea que debe ser algo como "escribir en la particion recovery 300000*512 bytes desde la posicion 0x40008000 de la memoria", que al no haber podido cargar el fichero tiene...?
Lo anterior? es decir algo de bootres y algo de ramdisk-uboot y algo del kernel..?
Casi mejor no intente arrancarlo...

jolocotroco · #**139** 04/08/13, 19:25:07

Hola amigos,
No he podido leer todo el hilo por falta de tiempo, mi tableta es algo diferente pero es de urbetter y con utscript.
Para recuperar el bootloader necesitais el .vhr para crear una sd de arranque, hay varios manuales en slatedroid, dropad a8, que os puede dar una idea. Si conseguis arrancar con el bootloader en la sd externa, este ejecutara utscript y asi podreis restaurar el bootloader interno, y todo el firmware.
Tambien es posible que la tabla de particiones este corrupta y sea necesario extraer la sd interna.

Hechando un vistazo rapido al firmware de Voyo

Al presionar la combinacion de teclas para actualizar, esto ejecuta el bootloader:

bootcmd
movi r k 0 40008000;movi r covery 0 40d00000 300000;bootm 40008000 40d0000
mmc rescan 1;fatload mmc 1 40000000 utscript;source 40000000;movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 4100000

Al iniciar:

bootargs=
bootcmd=mmc rescan 1;fatload mmc 1 40000000 utscript_1st;source 40000000; movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 4100000

No termino de entender pq ejecuta en los dos casos utscript, en mi tableta solo hay uno y se ejecuta en el primer caso y no para iniciar.
utscript_all y utscript_sys estan sin uso.
Al presionar la combinacion de teclas para actualizar si el bootloader no encuentra ningun utscript se ejecuta el recovery "movi r covery 0 40d00000 300000" esto al igual que en dropad a8, es un simple recovery que formatea las particiones, esa direccion es perfecta para un CWM.

beachsun · #**140** 04/08/13, 19:34:09

Hola Jolocotroco, primero gracias por pasarte a comentar....

Entiendo que lo que dices es que al rrancar con (-)(Pow) se ejcuta esto :

Cita: Originalmente Escrito por jolocotroco

bootcmd movi r k 0 40008000;movi r covery 0 40d00000 300000;bootm 40008000 40d0000 mmc rescan 1;fatload mmc 1 40000000 utscript;source 40000000;movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 4100000

Y al arrancar normal :

Cita: Originalmente Escrito por jolocotroco

bootargs= bootcmd=mmc rescan 1;fatload mmc 1 40000000 utscript_1st;source 40000000; movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 4100000

Como lo has deducido?
Que al encender normal ejecute el utscript_1st de mSD, lo pense hace unos dias pero Steve nos confirmo que encender la tablet normal, con la SD con los ficheros del updgrade, arranca Android normalmente. Bien pansado es un poco peligroso... No podria ser una combinacion de teclas?

Los siguientes 2 usuarios han agradecido a jolocotroco su comentario:
beachsun, STEVE_MARS

Gracias de parte de:
cpro