 |
|
||
|
#41
31/07/13, 21:09:52
|
||||
|
||||
 Cita: Originalmente Escrito por cpro
Si no me equivoco, no has tenido en cuenta que los bloques son de 512B por lo que si desplazas 0x80E00 10b a la derecha: sería 0x407 = 1031. Creo que se ve más sencillo si usamos los datos del script: MBR - 1 15KB - 30 16KB - 32 328KB - 656 156KB - 312 ENV(16) - 32 TOTAL: 1047 < 8192 Los archivos son más pequeños que el espacio reservado. Ten en cuenta que cada cargador tendrá codificada la dirección de inicio del siguiente.
 Lo que sigo sin entender es porque tienes en esa mSD la particion comenzando en el bloque 8192, no lo habia visto nunca, es decir esta desperdiciando 4 megas... algo se me escapa... Respecto al arranque, creo que estamos suponiendo( y esperando) lo mismo, que (+)(-)(pow) haga arrancar la tablet en el modo arranque sdBoot, tal y como se hace en la Arndale con los switches. Si realmente el de TabletRepublic lo ha conseguido ya tarda en dar mas informacion de como ha recuperado el Brick, ya que arrancar es solo el principio... No tengo muy claro que es la TrustZone. Pero si conseguimos arrancar la tablet en modo SdBoot, se podrian cargar/flashear los ficheros necesarios(kernel/root Image) de la misma SD (particiones). Cita: Originalmente Escrito por cpro
Pero para crear una mSD que arranque (si arranca) y ejecute el firm sin usar la eMMC, podríamos hacerlo sin más que considerarla la eMMC y copiar las cosas en la tarjeta (como hace "utscript") pero tenemos el problema de que el archivo "bootloader_sd.vhd" contiene el bl1, bl2, etc., apropiados y que imagino incluye una comprobación de la mSD que, si contiene "utscript", se pone a ejecutarlo.
|
| Gracias de parte de: | ||
|
|
|
#42
31/07/13, 21:25:12
|
||||
|
||||
|
Cita: Originalmente Escrito por beachsun
Lo que sigo sin entender es porque tienes en esa mSD la particion comenzando en el bloque 8192, no lo habia visto nunca, es decir esta desperdiciando 4 megas... algo se me escapa...
Cita: Originalmente Escrito por beachsun
No tengo muy claro que es la TrustZone.
Cita: Originalmente Escrito por beachsun
Pero si conseguimos arrancar la tablet en modo SdBoot, se podrian cargar/flashear los ficheros necesarios(kernel/root Image) de la misma SD (particiones).
Esto lo leo luego con calma que me he perdido... 
|
| Gracias de parte de: | ||
|
#43
31/07/13, 22:17:57
|
||||
|
||||
|
Cita: Originalmente Escrito por cpro
El primer sector de un disco siempre está en un cilindro y dicho cilindro no puede utilizarse en una partición: es normal que haya 2, 4, 8MB, según el disco y SO que lo particiona.
Correcto lo que dices, de hecho no me referia a que me extrañara perder X megas, ya que depende de la "geometria" del disco, sino a que no habia visto, en un formateo normal, una particion que comenzara en el bloque 8K. Volviendo a tu sd Código:
Disk /dev/sdg: 3947 MB, 3947888640 bytes, 7710720 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificador del disco: 0x00000000 Disposit. Inicio Comienzo Fin Bloques Id Sistema /dev/sdg1 8192 7710719 3851264 b W95 FAT32 No veo porque el primer bloque de tu particion no puede ser el 1. El primer cilindro que comentas seria el Bloque 0. Cita:A lo que me refiero es a que, si haces eso, al margen de cambiar los puntos de montaje, que es trivial, la carga no la vas a hacer con el firm de Arndale, debes hacerlo con el de Voyo y éste comprueba la tarjeta a ver si está "utscript" para ejecutarlo; aunque (pensándolo mejor) tampoco debería ser problema si no tienes un fichero que se llame así
Por otro lado revisando los links, aqui : http://users.elis.ugent.be/~nipennem/arndale hablan de linaro, que tambien tiene un arranque desde SD con el mismo sistema, y de linaro si que hay una imagen completa de la SD : http://releases.linaro.org/latest/ub...723-408.img.gz el resto de ficheros : http://releases.linaro.org/latest/ub...oards/arndale Me lo estoy bajando a ver que vemos de una imagen que se supone que funcionar en las arndale... Edito : Un giga la imagen ya descomprimida de la SD... casi na... aunque lo interesante esta en el primer mega...
Última edición por beachsun Día 31/07/13 a las 22:24:25.
|
| Gracias de parte de: | ||
|
#45
31/07/13, 23:29:09
|
||||
|
||||
|
Bueno, como avanza el tema.
Aqui uno se distrae un poco y habeis acabado con el tema .Bueno por que no mirais la estructura de la emmc interna, mmc 0. con un fdisk -l /dev/block/mmcblk0 vemos que la primera particion comienza en el bloque 9 y que cada bloque es de 8225260 bytes. Lo que nos deja espacio para los ficheros de boot. Se ubican hay los ficheros de boot?
|
| Gracias de parte de: | ||
|
#47
01/08/13, 11:15:02
|
||||
|
||||
|
Perdonad, pero ayer entre el curro y la familia no tuve tiempo de hacer nada.
beachsun, ¿que necesitas exactemente que te busque en el tablet?
|
|
#48
01/08/13, 11:31:17
|
||||
|
||||
|
Lo que comentaba era intentando responder a la pregunta de teredur :
Cita: Originalmente Escrito por teredur
Bueno por que no mirais la estructura de la emmc interna, mmc 0.
con un fdisk -l /dev/block/mmcblk0 vemos que la primera particion comienza en el bloque 9 y que cada bloque es de 8225260 bytes. Lo que nos deja espacio para los ficheros de boot. Se ubican hay los ficheros de boot? Luego por la tarde a ver si tengo un rato y reviso el fichero VHD del firmware, por que sospecho que es la imagen de lo que flashea para el boot, es decir lo que esta buscando teredur, los distintos ficheros que estamos revisando en raw.
|
|
#49
01/08/13, 11:55:56
|
||||
|
||||
|
Por cierto, aqui os dejo el github de namko, que para otras placas de Urbetter ha compilado un recovery simple, pero que permite flashear en .zip
https://github.com/namko/midRecovery A ver si por aqui tambien sacamos en claro.
|
|
#50
01/08/13, 12:31:57
|
||||
|
||||
|
¡Qué bueno es esto de aburrirse!
 Aviso de que es un poco largo.He estado echando una ojeada al archivo "utscript", según lo puesto en este hilo (mensaje #9) por teredu, descubriendo alguna cosilla interesante. 1.- Carga "set_bootargs" (variables de entorno de inicio) en la dirección 0x41000000: no sé si está expresada en valor absoluto pero, de serlo, reserva 130MB y lo copia a continuación. 2.- Borra la SD y genera las particiones de nuevo (fdisk). Si no me equivoco, reserva un espacio al principio de la memoria, crea las tres pariticiones (sistema, usuario y cache) con el tamaño indicado y una cuarta partición de datos usando el espacio libre. 3.- Copia el cargador "bootloader_sd.vhd" en la dirección 0x40008000: algo más allá de los 128MB. 4.- Copia 0x800 unidades desde la dirección 0x40008200: empieza en el byte 512. a.- El nombre ya sugiere que es una imagen de algo pero... es lógico si lo copia en la memoria tal cual.5.- Copia el archivo "misc" (16.4KB) a partir del bloque 407 y copia 20 unidades: a.- Si las unidades son 512B, está copiando sólo 10KB. Parece razonable que sean de 1KB.6.- Copia el kernel (zImage) en el espacio reservado para el núcleo (comandos w k de movi) a.- ¿La documentación de Android (o de fdisk) indica dónde está el espacio reservado al núcleo?7.- Hace lo propio con el disco de inicio (ramdisk-uboot.img) ¿en el espacio reservado para rootfs (w r)? a.- De éste (con el kernel no lo hace) copia 0x200000B = 2MB8.- Copia el logo de Voyo (en el espacio de logo). a.- Es un BMP 480x4809.- Hace lo mismo con el los de carga "bootres" a.- Es un BMP de 260x125 que ocupa 1MB10.- Copia el "ramdisk-recovery-uboot.img" que no existe a.- Lo copia en "c": no casa con bl1, ni bl2, ni u-boot...11.- Copia las imágenes de disco "system.img" y "userdata.img" Si supiéramos cómo funciona "fdisk", podríamos hacer la tarjeta a medida y puede que, incluso, arranque directamente de la SD, sin apretar botón alguno, si la tarjeta tiene el cargador apropiado: se podría comprobar de dónde arranca cambiando el logo de Voyo por otro, por ejemplo. Otra cosa a averiguar es qué hacen las instrucciones "mmc write" y "movi", si hay alguna página de manual. Y si aún estáis leyendo, permitidme esta suposición que, por supuesto, puede ser errónea. Al estar copiando en la eMMC, me parece absurdo copiarlo dos veces: de la mSD a la eMMC y dentro de la eMMC. Dado que el objetivo del controlador es evitar que unos bloques se utilien más que otros, quiero creer que el controlador modifica la dirección de acceso al bloque, en lugar de hacer otra copia (al menos, cuando usa "movi"). Y aunque podrían ser otros componentes, como el propio lector de tarjetas o una mala alimentación durante la actualización, pienso que esto reforzaría mi sospecha de que los aparatos mueren por fallo de la eMMC, porque una serie que han utilizado ha tenido más chips defectuosos de lo normal (o les salió más barata). En algún sitio vi, cuando murió la mia, que a los Samsung les pasaba por el firm de la eMMC, que iba corrompiendo la memoria NAND ¿por qué no podría ser algo parecido? Última edición por cpro Día 01/08/13 a las 12:43:53. Razón: indentación
|
|
#51
01/08/13, 12:51:40
|
||||
|
||||
|
Y una pregunta simple y muy tonta...
¿Porque no dejamos solo que copie el kernel, system.img y userdata.img? De esa forma evitamos que escriba en la eMMC y eliminamos la posibilidad de bricks. Al fin y al cabo, el bootloader no cambiará hasta que actualizen la version de Android, y no creo que saquen 4.3 oficial para nuestra tablet.
|
|
#52
01/08/13, 13:08:09
|
||||
|
||||
|
Cita: Originalmente Escrito por STEVE_MARS
Y una pregunta simple y muy tonta...
¿Porque no dejamos solo que copie el kernel, system.img y userdata.img? De esa forma evitamos que escriba en la eMMC y eliminamos la posibilidad de bricks. Al fin y al cabo, el bootloader no cambiará hasta que actualizen la version de Android, y no creo que saquen 4.3 oficial para nuestra tablet. Deberías copiar también el ramdisk (cambiará si ha cambiado el kernel) y formatear las dos (seguramente, las tres) particiones. Y sí, a priori, minoras el riesgo, pero no lo eliminas; y si es problema del controlador de la eMMC, no tendría relevancia, pero el fichero de la inspiration ocuparía menos y se actualizaría antes ¡Ah! y no se eliminaría lo que hubieras copiado a la memoria.
|
|
#53
01/08/13, 13:14:10
|
||||
|
||||
|
Creo que, tal y como arranca la Tablet con (-)+(Pow) es en modo "Arranque desde eMMC" por lo que Device 0 es la eMMC y el 1 la SD.
Si arrancara en modo "Boot SD" la numeración se invierte. Relee el script teniendo en cuenta eso, y veras que no particiona la SD, sino la eMMC, si lo hiciera te dejaria la SD sin poder leerlar despues de flashear, ya que se habría cargado las particiones que tuvieras. No me parece que copie la información dos veces, de la mSD a la eMMc, y despues de eMMC a eMMC. Fatload debe cargar en Ram, así , el movimiento de los datos es : - Se lee fichero de la mSD -> RAM - Se Flashea de RAM -> eMMC
|
|
#54
01/08/13, 13:17:50
|
||||
|
||||
|
Pues propongo lo siguiente:
Un utscript para cada caso, es decir - si no cambia el kernel, solo system.img y userdata.img (¿se podra hacer wipe de dalvik y cache desde utscript?). Asi podremos hacer actualizaciones de rom´s sin perder nuestras app y configuraciones. -si cambia el kernel, ramdisk, kernel, system y userdata. En caso que cambie el kernel, podemos formatear las particiones y entonces perderemos todo porque seria una instalacion limpia. -si cambia el bootloader, es decir la version de Android, todo tal como esta actualmente. ¿Es correcto o me he fumado algo bueno? 
|
|
#55
01/08/13, 13:28:11
|
||||
|
||||
|
Comentando con josemacl, que ha preparado una ROM para lña Hyundai T7s (exynos 4412) tambien de Urbetter, sobre solo instalar kernel, system y userdata, me manda esto:
Código:
OK, voy a pegar a continuación el utscript de la T7s y voy a poner en negrita las líneas que quitaría. Básicamente son las que formatean y particionan algo... a ver si te cuadra (he visto varios utscript y son todos primos-hermanos). Como puedes ver, quitando esas líneas los únicos ficheros que se cargarían son el zImage (kernel), system.img (/system) y userdata.img (/data). Tengo dudas con las líneas en cursiva, porque parece que lo que hace es simplemente borrar la parte de usuario, sin reparticionar ni formatear. También con la parte que carga el fichero misc, que contiene variables de entorno que luego se actualizan con la línea refreshenv. ¡Encantado de comentar cosillas contigo! Saludos. ================================================================= fatload mmc 1 0x41000000 set_bootargs source 0x41000000 utupdateenv utsetbacklight 1 uttext 20 30 "***********************************************" uttext 20 40 "* Exynos4 upgrade Android4.2 V0.1 [all]" uttext 20 50 "***********************************************" uttext 20 60 " " uttext 20 70 " T7sSPClean2GBv1.01 by spektro AKA josemacl " uttext 20 80 " " uttext 20 90 "Erase, partition memory and update bootloader..." mmc erase boot 0 0 0 mmc erase user 0 0 0 fdisk -c 0 512 2000 500 mmc rescan 0;mmc rescan 1 fatload mmc 1 0x40008000 bootloader_sd.vhd emmc open 0;mmc write 0 0x40008200 0x0 0x800;emmc close 0 fatload mmc 1 0x40008000 misc mmc write 0 0x40008000 407 20 refreshenv uttext 20 100 "Done" uttext 20 110 "Update kernel..." fatload mmc 1 0x40008000 zImage movi w k 0 0x40008000 uttext 20 120 "Done" uttext 20 130 "Update ramdisk..." fatload mmc 1 0x40008000 ramdisk-uboot.img movi w r 0 0x40008000 200000 uttext 20 140 "Done" uttext 20 150 "Update logo and battery charge image..." fatload mmc 1 0x40008000 logo.bmp movi w l 0 0x40008000 400000 fatload mmc 1 0x40008000 bootres movi w l 0 0x40008000 100000 11 uttext 20 160 "Done" uttext 20 180 "Update system, wait some minutes..." movi init 0 sleep 50 fatformat mmc 0:1 ext3format mmc 0:3 ext3format mmc 0:4 sleep 50 fatload mmc 1 0x48000000 system.img fastboot flash system 48000000 uttext 20 190 "Done" sleep 50 uttext 20 200 "Update 2GB userdata, wait some minutes..." fatload mmc 1 0x48000000 userdata.img fastboot flash userdata 48000000 uttext 20 210 "Update completed!" sleep 500 uttext 20 230 "Please, reboot your device..." sleep 4000
|
|
#56
01/08/13, 13:35:02
|
||||
|
||||
|
Pues que como el mismo dice, solo deja vivo el Kernel, System y Data.
Yo no quitaria "mmc rescan 0", si no estoy equivocado lo que hace es releer la "unidad", es como hacer F5. De echo me sobraría el mmc rescan 1, ya que a la SD no le has hecho nada... quizas sirva de inicializacion. Yo haria Kernel, Ramdisk, System y Data.
|
|
#57
01/08/13, 13:45:30
|
||||
|
||||
|
Cita: Originalmente Escrito por STEVE_MARS
¿Que os parece?
Pero las aplicaciones instaladas las perderías siempre que reemplazaras "system.img" y "userdata.img", si no me equivoco. Última edición por cpro Día 01/08/13 a las 14:04:07.
|
|
#58
01/08/13, 13:59:25
|
||||
|
||||
|
Cita: Originalmente Escrito por beachsun
Relee el script teniendo en cuenta eso, y veras que no particiona la SD, sino la eMMC, si lo hiciera te dejaria la SD sin poder leerlar despues de flashear, ya que se habría cargado las particiones que tuvieras.
Cita: Originalmente Escrito por beachsun
No me parece que copie la información dos veces, de la mSD a la eMMc, y despues de eMMC a eMMC.
Fatload debe cargar en Ram, así , el movimiento de los datos es : - Se lee fichero de la mSD -> RAM - Se Flashea de RAM -> eMMC
|
|
#59
01/08/13, 14:24:00
|
||||
|
||||
|
Cita: Originalmente Escrito por beachsun
Pues que como el mismo dice, solo deja vivo el Kernel, System y Data.
Yo no quitaria "mmc rescan 0", si no estoy equivocado lo que hace es releer la "unidad", es como hacer F5. De echo me sobraría el mmc rescan 1, ya que a la SD no le has hecho nada... quizas sirva de inicializacion. Yo haria Kernel, Ramdisk, System y Data. Aunque no particionamos el user data a 2Gb. Código:
utsetbacklight 0 shut 1 reset sleep 1000
|
|
|
|
#60
01/08/13, 14:42:59
|
||||
|
||||
|
Cita: Originalmente Escrito por cpro
Me refiero a que, si sabemos dónde hay que colocar cada cosa, podríamos (re)crear un tarjeta SD que (tal vez) funcionara sin usar la eMMC. Si en un aparato muerto el no encenderse fuera, por ejemplo, porque no se enciende el LCD, sí se encendería si arrancara desde la SD.
Por ejemplo, se me ocurre que, si arrancamos así con una SD preparada para Flashear, no debería actualizar el Firm... Hasta que se confirme la activacion de ese modo de boot hay varias vias de investigacion para una tablet que puede "actualizarse" : - El flasheo sin modificar el Boot - No flashear, sino arrancar el SO desde la SD. La verdad es que no se me había ocurrido DMA entre una mSD y una Nand, pero me suena raro... Me encaja mas mi teoria, pero no deja de ser eso...
|
 |
Estás aquí
|
||||||
|
||||||
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/unknown.gif)
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar73903_1.gif){kind=avatar}
