Estado del desarrollo de la SD de recuperacion

[STEVE_MARS]

Buenas tardes a todos.

Para poder ir resumiendo todos los avances del desarrollo de la SD de recuperacion para las tablets brickeadas, creamos este hilo y asi será mas facil que vayais siguiendo la evolucion.
Por favor, en este hilo solo vamos a ir resumiendo los avances, para postear con ideas, nuevas lineas de desarrollo, etc., lo vamos a seguir haciendo en el hilo anterior, http://www.htcmania.com/showthread.php?t=653942

Quiero dar las gracias especialmente a beachsun, cpro y teredur (no este orden, a los tres por igual ) por su ayuda y sus conocimientos puestos a disposicion de todos.
Y el resumen ha sido iniciativa de cpro, que se ha pegada la currada de hacerlo, que no era nada facil. Han sido varios dias de tormenta de ideas .

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"?

Conseguido el bootloader_mmc.bin, fichero importante para crear Custom Rom seguras.

[sllf]

Agradezco la currada, aunque no entienda nada, compañeros ya que sé que es por el bien de todos y que sabéis lo que hacéis. Lo dicho, muchas gracias y ánimo!

[knifeboy]

Estais hechos unos cracks!!!!

[exxtrema]

gracias a todos los componentes de este equipo!!!!

[STEVE_MARS]

Otro avance , ya tenemos el bootloader_mmc.bin. Este fichero es importante

[javiorz]

Sois unos cracks !! Adelante !!

[Cacique_]

Valla cracks estais hechos, gracias por vuestro esfuerzo

[RUBIO8707]

que flipada de makinas estais echos, yo ni idea pero un OLE para vosotros