Posible solucion a los brickeos

**STEVE_MARS** · #1 29/07/13, 09:08:07

Hola.
Os paso el enlace de un usuario de tabletrepublic que dice que ha encontrado una solucion a los brickeos. Incluso dice que él mismo ha reparado su tablet de esta forma.
Yo he estado revisando la web y no veo la forma de hacerlo, le he preguntado si nos puede pasar los ficheros necesarios para crear una especie de "sdcard de recuperacion".
http://tabletrepublic.com/forum/cort...lets-4714.html

Y este el link de la web en cuestion:
http://www.arndaleboard.org/wiki/ind...26_Accessories

Sigo atento por si se produjera alguna novedad al respecto.

teredur · #2 29/07/13, 09:28:45

Buena noticia.

En principio parece realizable.
Una img de la sdcard de recuperacion , nos ahorraria mucho tiempo.
Aunque ya estoy descargando ubuntu para intentar realizar el proceso.

rivermon · #3 29/07/13, 09:58:49

Eso sería un notición
Y otro grande sería que fabricante de soc y voto se pusieran las pilas y os agradecise la currada que con STEVE_MARS a la cabeza os estáis pegando

**STEVE_MARS** · #4 29/07/13, 10:06:54

Yo empiezo hoy a currar y voy a tener menos tiempo, pero intentare esta noche ponerme en el portatil que tiene Linux a ver que saco.

Manzano90 · #5 29/07/13, 22:35:25

Yo esque no entiendo mucho y no se que hay que hacer..! Si alguien encuentra la solucion,o necesita a alguien con una tablet brickeada, que me diga algo..aver si encontramos la solucion!!

**STEVE_MARS** · #6 30/07/13, 09:15:13

Nueva informacion con mas datos y ademas con el u-boot.img compilado para la Arndale board.
Sigo investigando...
https://fedoraproject.org/wiki/Arndale_Board

beachsun · #7 30/07/13, 14:35:08

Borrador de Idea : revisar los utscripts para no "regrabar" el "boot".
Es decir ver si se puede identificar uno de los ficheros como el u-boot y modificar el utscript para que no lo flashee.
En ese caso por mucho que falle el flasheo únicamente no cargara la ROM, pero se podra volver a flashear...

Disculpas por adelantado si no tiene sentido o ya se ha intentado...

**STEVE_MARS** · #8 30/07/13, 16:02:21

Efectivamente esa es la clave, pero no es tan facil.
El UTscript no es texto plano, se hace con el programa mkimage bajo Linux, y hay que saber que parametros poner, de los cuales no tengo ni zorra idea.
He preguntado en varios foros y todos estan tan pez como yo, pero sigo intentandolo.

teredur · #9 30/07/13, 16:25:38

Para ir abriendo boca con el utscript, aqui lo teneis pasado a txt y con algun comentario.

Código:

fatload mmc 1 0x41000000 set_bootargs
    # carga el fichero set_bootargs de la mmc 1 (emmc sd) en la direccion hex 
    #fatload - load binary file from a dos filesystem
        <interface> <dev[:part]>  <addr> <filename> [bytes]
        - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from dos filesystem
source 0x41000000 
    # source
    run script from memory
    [addr]
    - run script starting at addr
    - A valid image header must be present minimal test like /bin/sh
utupdateenv
    # utupdateenv - read environment and do changes immediately
utsetbacklight 1
    # utsetbacklight   - utsetbacklight [x] x : 0[off] or 1[on]
    lcd backlight switch
uttext  20 30 "**********************************************"
uttext  20 40 "* Exynos5 upgrade JB2 V0.1[utscript]"
uttext  20 50 "**********************************************"
uttext  20 60 "    
uttext  20 70 "Update bootloader..."
uttext  20 80 "mmc erase boot 0 0 0"
mmc erase user 0 0 0
    # mmc erase <boot | user> <device num> <start block> <block count>
fdisk -c 0 512 1000 500
    # fdisk <-c> <device_num> [<sys. part size(MB)> <user data part size> <cache part size>]
     creacion particiones
mmc rescan 0
mmc rescan 1
    #mmc rescan <device num>
fatload mmc 1 0x40008000 bootloader_sd.vhd
emmc open 0
    #Open/Close eMMC boot Partition
    emmc open <device num> 
    emmc close <device num> 
mmc write 0 0x40008200 0x0 0x800
    #mmc write <device num> addr blk# cnt
emmc close 0
fatload mmc 1 0x40008000 misc
mmc write 0 0x40008000 407 20
refreshenv
uttext  20 80 "Done."
uttext  20 90 "Update kernel..."
fatload mmc 1 0x40008000 zImage
movi w k 0 0x40008000
        #movi    - sd/mmc r/w sub system for SMDK board
            init - Initialize moviNAND and show card info
            movi read zero {fwbl1 | bl2 |u-boot} {device_number} {addr} - Read data from sd/mmc
            movi write zero {fwbl1 | bl2 |u-boot} {device_number} {addr} - Write data from sd/mmc
            movi read {u-boot | kernel} {device_number} {addr} - Read data from sd/mmc
            movi write {fwbl1 | u-boot | kernel} {device_number} {addr} - Write data to sd/mmc
            movi read rootfs {device_number} {addr} [bytes(hex)] - Read rootfs data from sd/mmc by size
            movi write rootfs {device_number} {addr} [bytes(hex)] - Write rootfs data to sd/mmc by size
            movi read  logo {addr} [bytes(hex)] - Read logo data from sd/mmc by size
            movi write logo {addr} [bytes(hex)] - Write logo data to sd/mmc by size
            movi read {sector#} {device_number} {bytes(hex)} {addr} - instead of this, you can use "mmc read"
            movi write {sector#} {device_number} {bytes(hex)} {addr} - instead of this, you can use "mmc write"
uttext  20 100 "#Done."
uttext  20 110 "Update ramdisk..."
fatload mmc 1 0x40008000 ramdisk-uboot.img
movi w r 0 0x40008000 200000
uttext  20 120 "Done."
uttext  20 130 "Update logo"
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 140 "Done."
uttext  20 150 "Update recovery"
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."
movi init 0
sleep 50
    #delay execution for some time
    - delay execution for N seconds (N is _decimal_ !!!)
fatformat mmc 0:1
    #fatformat - disk format by FAT32
    <interface(only support mmc)> <dev:partition num>
    - format by FAT32 on 'interface'
ext4format mmc 0:3
ext4format mmc 0:4
sleep 50
fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000
    #fastboot- use USB Fastboot protocol
    - Run as a fastboot usb device.
    - The optional inactive timeout is the decimal seconds before
    - the normal console resumes
    usage : fatformat <interface> <dev[:part]>
sleep 50
uttext  20 190 "Update userdata...Wait some minutes."
fatload mmc 1 0x48000000 userdata.img
fastboot flash userdata 48000000
uttext  20 200 "OK, Update End !"
sleep 500
uttext  20 220 "Reboot..."
sleep 2000
utsetbacklight 0
shut 1
reset
    #reset - reset (rescan) USB controller

**STEVE_MARS** · #10 30/07/13, 16:48:31

He decompilado el userdata.img y solo lleva dos aplicaciones que las instala aparte, el scanner ese de tarjetas de visitas y otra irrelevante, podemos eliminarlo del flasheo.

Si tenemos claro que las direcciones del utscript son correctas, podemos compilarlo con mkimage y hacer una prueba. Y de camino aumentar la partición data a 2 gb., ¿que opinas?.

Estupendo, teredur

**STEVE_MARS** · #11 30/07/13, 16:49:48

Sabes el motivo de porqué hay utscript normal, sd, all...???

beachsun · #12 30/07/13, 17:09:16

Bueno, creo que he visto como se crea el fichero utscript :
mkimage -T script -C gzip -d FichTextoScript -n 'Script Created by Win32' -O Linux -A ARM NombreUtScript

Donde :
FichTextoScript : es el nombre del fichero script con los comandos.
'Script Created by Win32' : es el nombre de la imagen -> Como desconozco si es critico para su funcionamiento he puesto lo mismo que el que viene en la instalacion.
NombreUtScript : El nombre del fichero imagen de salida.

Al fichero de salida le falta rellenar con 0's hasta que el tamaño final del fichero sea 65.536 Bytes -> probablemente cualquier multiplo de 65.536 sea valido.

Comparando el resultado de un files y el mkimage -l de un fichero creado por mi con el mkimage y el utscript original "recortado" al tamaño del Script(es decir quitando los 0's de mas) me devuelven la misma informacion.

**STEVE_MARS** · #13 30/07/13, 17:18:52

Cojonudo, beachsun.
Nos acercamos a la solucion, los tenemos rodeados

.
Ahora bien, ¿cual compilamos, el normal, el sd, el all... o todos?

**STEVE_MARS** · #14 30/07/13, 17:23:47

Por cierto, ya he localizado los binarios para crear la SD de recuperacion, junto al u-boot.img.
No he podido compilarlo, me da un error, pero sigo en ello.
Lo he sacado de aqui:
http://forum.insignal.co.kr/viewtopic.php?t=63
de aqui:
http://users.elis.ugent.be/~nipennem/arndale
y de aqui:
http://forum.insignal.co.kr/viewforum.php?f=10
En esta ultima están tambien las compilaciones en Linaro, para que podamos ir viendo si podemos recompilar el kernel con Linaro.

Y el u-boot.img de aqui (descomprimido son 3 gb. ¡¡¡ )
http://tekkamanninja.fedorapeople.or...rndale/images

Ah, y tambien tengo el .c con las resoluciones del LCD, por si podemos hacer algo con el degradado de colores.
http://forum.insignal.co.kr/viewtopic.php?f=7&t=2453

beachsun · #15 30/07/13, 17:29:23

Quizas lo primero es comparar los distintos scripts a ver que cambia entre ellos.
Eso nos aportara informacion.

Tambien seria interesante saber si alguno de los textos que se "imprimen" con el uttext se ven en pantalla, por ejemplo : uttext 20 40 "* Exynos5 upgrade JB2 V0.1[utscript]"
si eso lo podemos ver por pantalla o serie, podemos saber cual se ejecuta con cada pulsacion de teclas.

beachsun · #16 30/07/13, 17:38:49

Tomando como baso el utscript que ha puesto el compañero teredur :
utscript_1st = utscript_all = utscript +

Código:

uttext  20 80 "mmc erase boot 0 0 0"
mmc erase boot 0 0 0
uttext  20 80 "mmc erase user 0 0 0"
mmc erase user 0 0 0

utscript_sys = utscrip +
No hace :

Código:

mmc erase user 0 0 0
....
fatload mmc 1 0x40008000 misc
mmc write 0 0x40008000 407 20

y al final del script tiene esto

Código:

###### comment start
mmc rescan 0;mmc rescan 1

fatload mmc 1 0x40008000 bootloader_mmc.bin
emmc open 0;mmc write 0 0x40008000 0x0 0x800;emmc close 0

fatload mmc 1 0x40008000 misc
mmc write 0 0x40008000 407 20


###### comment end

Que no tengo claro que se ejecute, para empezar porque los ficheros a los que hace referencia no estan en el firmware.

PhoenixTR · #17 30/07/13, 19:20:53

Pregunta de ignorante. ¿creeis que con esto se pueden recuperar la muertas?, es que si ni siquiera encienden no acabo de ver como valdría para algo.

beachsun · #18 30/07/13, 19:26:43

La verdad es que si no enciende, no creo que ayude.
Si enciende pero tiene fastidiado el boot, quizas si.

Lo que me hace plantearme si los "bricks", mas que tablets con el boot corrupto son tablets que no encienden...

PhoenixTR · #19 30/07/13, 19:32:26

Hombre dejan de encenderse después de apagarse al finalizar la actualización, con lo que algo les hace la actualización para dejarlas muertas.

beachsun · #20 30/07/13, 19:33:31

Que te parece este script Steve??

Código:

[YaMeGustaria Mode on]
fatload mmc 1 40008000 zImage
setenv bootargs root=/dev/mmcblk1p? (Localizar particion de la SD en EXT4 con un root instalado) rootfstype=ext4 init=/init console=ttySAC2,115200 
bootm 40008000 
[YaMeGustaria Mode Off]

Soñar es gratis!!

Los siguientes 4 usuarios han agradecido a STEVE_MARS su comentario:
[ Mostrar/Ocultar listado de agradecimientos ]

Los siguientes 2 usuarios han agradecido a teredur su comentario:
robepoke, tuti34

Los siguientes 2 usuarios han agradecido a STEVE_MARS su comentario:
exxtrema, tuti34

Gracias de parte de:
tachen

Gracias de parte de:
tuti34

Gracias de parte de:
tuti34

Gracias de parte de:
tuti34