Posible solucion a los brickeos

[STEVE_MARS]

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/cortex-a15-samsung-exynos-5250/solution-repair-bricked-exynos-5-tablets-4714.html

Y este el link de la web en cuestion:
http://www.arndaleboard.org/wiki/index.php/WiKi#Arndale_Board_Packages_.26_Accessories

Sigo atento por si se produjera alguna novedad al respecto.

[teredur]

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]

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]

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]

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]

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]

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]

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]

Para ir abriendo boca con el utscript, aqui lo teneis pasado a txt y con algun comentario.
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]

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 :platano:

[STEVE_MARS]

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

[beachsun]

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]

Cojonudo, beachsun.
Nos acercamos a la solucion, los tenemos rodeados :risitas:.
Ahora bien, ¿cual compilamos, el normal, el sd, el all... o todos?

[STEVE_MARS]

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.org/boards/arndale/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]

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]

Tomando como baso el utscript que ha puesto el compañero teredur :
utscript_1st = utscript_all = utscript +
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 :
mmc erase user 0 0 0
....
fatload mmc 1 0x40008000 misc
mmc write 0 0x40008000 407 20

y al final del script tiene esto

###### 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]

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]

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]

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]

Que te parece este script Steve??
[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!!

[beachsun]

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.
No se pueden actualizar de nuevo? si no se puede lo veo complicado, ya que todo esto se basa en el sistema que tiene para actualizar...

[cpro]

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.

Viendo los últimos comentarios y fotos... yo me animaría a abrirla y comprobar si no se ha metido para dentro la plaquita y el botón de encendido no hace contacto. Si fuera eso te ahorras los dineros (y las tres semanas) de viajar a China.

[PhoenixTR]

Viendo los últimos comentarios y fotos... yo me animaría a abrirla y comprobar si no se ha metido para dentro la plaquita y el botón de encendido no hace contacto. Si fuera eso te ahorras los dineros (y las tres semanas) de viajar a China.


Ojala fuera eso, lo botones de volumen, power y el reset hacen el click cuando los pulsas por lo que no creo que sea un mal contacto.

[teredur]

Por lo que he visto durante las actualizaciones. y tengo grabada una en video.
EL script que se ejecuta es el utscript.
Ya que el texto mostrado es el de los comanods uttext.

[beachsun]

Genial, así se puede comenzar haciendo pruebas sin Flashear...

Veo dos vías paralelas de trabajo :
- Intentar flasheo sin machacar el boot
- Intentar un arranque desde SD sin flashear

[STEVE_MARS]

Por lo que he visto durante las actualizaciones. y tengo grabada una en video.
EL script que se ejecuta es el utscript.
Ya que el texto mostrado es el de los comanods uttext.

Perfecto, podemos compilar un nuevo utscript sin escribir el boot, y dejando solo este utscript.
Aqui os dejo el mkimage para usar bajo windows, gentileza de Sp4ceM4rine del foro de Staledroid.
http://ubuntuforums.org/showpost.php?p=8629000&postcount=105

[STEVE_MARS]

Genial, así se puede comenzar haciendo pruebas sin Flashear...

Veo dos vías paralelas de trabajo :
- Intentar flasheo sin machacar el boot
- Intentar un arranque desde SD sin flashear

Efectivamente, creo que es mas prioritario la SD de recuperacion para los compañeros a los que se les ha muerto el tablet.

[STEVE_MARS]

Aqui esta, paso a paso, como preparar la SD:

$ sudo fdisk -l
Disk /dev/sde: 8018 MB, 8018460672 bytes
219 heads, 12 sectors/track, 5959 cylinders
Units = cylinders of 2628 * 512 = 1345536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 4 5960 7826432 b W95 FAT32

$ mksdboot /dev/sde1

STEP 1. check device
brw-rw---- 1 root disk 8, 65 2013-01-11 15:02 /dev/sde1

STEP 2. confirm device
continue ()? [Y/n]:

STEP 3. check file
-rwxr-xr-x 1 seanpa04 seanpa04 15360 2012-12-03 22:44 /home/seanpa04/arndale/WORKING_DIRECTORY/vendor/insignal/arndale/exynos5250/exynos5250.bl1.bin
-rw-r--r-- 1 seanpa04 seanpa04 14336 2013-01-04 12:55 /home/seanpa04/arndale/WORKING_DIRECTORY/u-boot/bl2.bin
-rw-r--r-- 1 seanpa04 seanpa04 256428 2013-01-04 12:55 /home/seanpa04/arndale/WORKING_DIRECTORY/u-boot/u-boot.bin
-rwxr-xr-x 1 seanpa04 seanpa04 94208 2012-12-03 22:44 /home/seanpa04/arndale/WORKING_DIRECTORY/vendor/insignal/arndale/exynos5250/exynos5250.tzsw.bin

STEP 4. unmounting partitions

STEP 5. clean up boot area
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 0.0577286 s, 284 kB/s

STEP 6. copy/fusing files
30+0 records in
30+0 records out
15360 bytes (15 kB) copied, 1.0143 s, 15.1 kB/s
28+0 records in
28+0 records out
14336 bytes (14 kB) copied, 0.752604 s, 19.0 kB/s
500+1 records in
500+1 records out
256428 bytes (256 kB) copied, 7.08218 s, 36.2 kB/s
184+0 records in
184+0 records out
94208 bytes (94 kB) copied, 2.73305 s, 34.5 kB/s
STEP 6. Completed.
Fuse time = 14 sec.Sacado de aqui:
http://forum.insignal.co.kr/viewtopic.php?f=10&t=346

Estoy currando y no puedo comprobarlo hasta esta noche, lo dejo por si alguien puede hacer algo mientras.

[teredur]

Efectivamente, creo que es mas prioritario la SD de recuperacion para los compañeros a los que se les ha muerto el tablet.

Soy de la misma opinion, nos permitiria incluso probar ROM's sin tener que flasear.

[PhoenixTR]

Aqui esta, paso a paso, como preparar la SD:

$ sudo fdisk -l
Disk /dev/sde: 8018 MB, 8018460672 bytes
219 heads, 12 sectors/track, 5959 cylinders
Units = cylinders of 2628 * 512 = 1345536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 4 5960 7826432 b W95 FAT32

$ mksdboot /dev/sde1

STEP 1. check device
brw-rw---- 1 root disk 8, 65 2013-01-11 15:02 /dev/sde1

STEP 2. confirm device
continue ()? [Y/n]:

STEP 3. check file
-rwxr-xr-x 1 seanpa04 seanpa04 15360 2012-12-03 22:44 /home/seanpa04/arndale/WORKING_DIRECTORY/vendor/insignal/arndale/exynos5250/exynos5250.bl1.bin
-rw-r--r-- 1 seanpa04 seanpa04 14336 2013-01-04 12:55 /home/seanpa04/arndale/WORKING_DIRECTORY/u-boot/bl2.bin
-rw-r--r-- 1 seanpa04 seanpa04 256428 2013-01-04 12:55 /home/seanpa04/arndale/WORKING_DIRECTORY/u-boot/u-boot.bin
-rwxr-xr-x 1 seanpa04 seanpa04 94208 2012-12-03 22:44 /home/seanpa04/arndale/WORKING_DIRECTORY/vendor/insignal/arndale/exynos5250/exynos5250.tzsw.bin

STEP 4. unmounting partitions

STEP 5. clean up boot area
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 0.0577286 s, 284 kB/s

STEP 6. copy/fusing files
30+0 records in
30+0 records out
15360 bytes (15 kB) copied, 1.0143 s, 15.1 kB/s
28+0 records in
28+0 records out
14336 bytes (14 kB) copied, 0.752604 s, 19.0 kB/s
500+1 records in
500+1 records out
256428 bytes (256 kB) copied, 7.08218 s, 36.2 kB/s
184+0 records in
184+0 records out
94208 bytes (94 kB) copied, 2.73305 s, 34.5 kB/s
STEP 6. Completed.
Fuse time = 14 sec.Sacado de aqui:
http://forum.insignal.co.kr/viewtopic.php?f=10&t=346

Estoy currando y no puedo comprobarlo hasta esta noche, lo dejo por si alguien puede hacer algo mientras.


Y esto traducido a lenguaje normal, ¿que hay que hacer para preparar esa SD?, estoy a punto de mandar la voyo de vuelta a china, ¿crees que con esto hay posibilidad de recuperar las muertas después de actualizar que ni encienden?, lo digo por esperar a mandarla o mandarla ya.

[STEVE_MARS]

Pufff, es dificil decir que si.
Si Voyo no ha logrado esto en meses, y nosotros lo hacemos en dias, ¿nos daran el Oscar?.
En serio, toma la decision que creas mas conveniente, puede ser que a la primera demos con la tecla o que no funcione.
Ademas, ten en cuenta que esto esta basado en la Arndale board, una placa experimental con el A15-Exynos 5250. Que yo sepa nadie lo ha probado sobre el tablet.

[STEVE_MARS]

Bueno, pues he preparado la SD segun todos los tuto, y lo hace correctamente.
Pero despues la SD esta vacia, sin embargo cuando hago el proceso se ve como escribe en ella.
Todo lo hago en Linux, ¿alguna idea?.

[STEVE_MARS]

En Slatedroid tambien vamos dando pasos, esto es lo que ha hecho Spacemarine:

On another topic, I did some work to get the system partition to 2Go. Here’s what I did so far:
1- Rename utscript to utscript.txt
2- Open utscript.txt with VIM editor
3- Delete all the symbols before the first command line in the script. After deletion, the first line should be” fatload mmc 1 0x41000000 set_bootargs”
4- Edit the script to get a 2Go sys partition
5- Save the script, exit VIM.
6- Open a command line and with mkimage do:
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Script Created by Win32" -d utscript.txt utscript
7- I did steps 1 to 6 for the other 3 files: utscript_1st, utscript_all, utscript_sys.

In order to get a 2Go partition, I made those modifications to the script:

From fdisk -c 0 512 1000 500 to fdisk -c 0 512 2000 500 and I also did
From fdisk -c 0 512 1000 500 to fdisk -c 0 1024 1000 500

Then I flashed the Voyo with the modified scripts. The scripts seemed to work because the tablet booted normally and installed the image without errors, BUT once booted into Android, the partitions where of the SAME size with either modifications. Tonight I’ll try with 2048 1000 500, because I read somewhere that the syntax of U-boot fdisk is supposed to be:
-c = the partition is readable by windows
0 = disk number
512 = System partition size
1000 = App partition size
500 = Cache partition size

[beachsun]

Bueno, pues he preparado la SD segun todos los tuto, y lo hace correctamente.
Pero despues la SD esta vacia, sin embargo cuando hago el proceso se ve como escribe en ella.
Todo lo hago en Linux, ¿alguna idea?.

La verdad, es que lo que me extraña es que te mantenga el FS de la SD.
Por lo que he visto el Script lo que hace es copiar "a pelo" los 4 ficheros uno detras del otro :
exec_cmd dd iflag=dsync oflag=dsync if="$1" of="${DEVICE}" bs=512 seek=$2
Comenzando en el Offset 1 y continuando el resto justo detras del anterior, por lo que es posible que la SD este bien, pero lo que no se es como hacer que la tablet al arrancar haga el boot desde esos ficheros de la SD.

[cpro]

La verdad, es que lo que me extraña es que te mantenga el FS de la SD.
Por lo que he visto el Script lo que hace es copiar "a pelo" los 4 ficheros uno detras del otro :
exec_cmd dd iflag=dsync oflag=dsync if="$1" of="${DEVICE}" bs=512 seek=$2
Comenzando en el Offset 1 y continuando el resto justo detras del anterior, por lo que es posible que la SD este bien, pero lo que no se es como hacer que la tablet al arrancar haga el boot desde esos ficheros de la SD.

Por las cosas que M$ hace cuando formatea (crea particiones). Esto es -según fdisk- una mSD de 4GB formateada en FAT32 por W7:

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

En este enlace http://users.elis.ugent.be/~nipennem/arndale/ que puso STEVE cuentan las direcciones que ocupa cada archivo: hay espacio suficiente desde el MBR hasta que comienza la partición. Y si arranca desde la mSD, supongo, es por ser el dispositivo por defecto y tener el cargador en el sector 1; si no, lo intenta con la eMMC.

[beachsun]

No entiendo lo de que hay espacio desde que acaba el MBR hasta que comienza la particion.

Te cuento lo que yo entiendo :
- No sabemos que mbr, y por tanto que tabla de particiones tenia la sd de Steve.
- El Script no toca para nada la MBR, por tanto se mantiene la anterior
- El Script, al menos el que he visto, pone a 0 desde 0x80E00 durante 16Kb
- El script copia en raw los bytes de los ficheros comentados a partir de la posicion 512. Ademas tiene hardcoded los tamaños de lo que copia por lo que mas vale que los ficheros realmente sean de ese tamaño o inferior.
- La copia de datos termina en el offset : 0x80DFF -> 527871 Por lo que todo lo que existiera hasta aqui se ha machacado(probablemente se hubiera comido la fat de la particion que existiera, por ejemplo la de tu mSD de 4GB).
- Desde 0x80E00 se reservan 16 Kb(antes puestos a 0) para U-Boot environment
- Por tanto tenemos a partir de 0x84E00 (casi mejor a partir de 0x8A200 que es el mayor de las tres versiones marcadas en la tabla) para crear las particiones, fat32, ext4, etc donde poner el kernel, el root, etc...

Es decir la tabla de particiones de la SD deberia tener la primera particion, por ejemplo de tipo Fat32, a partir de 0x84E00 (si prefieres a partir de 0x8A200 por mayor seguridad).

Por eso digo que me extraña que pueda hacer un ls sin que de error. De hecho me extraña que pueda montar la SD ya que se carga la posible 1a particion escribiendo en raw a partir de la MBR.

Finalmente como bien dice la pagina comentada, lo que hace el script no coincide con lo que indican en la Wiki. El tema esta turbio.


Y respecto al arranque, me temo que la configuracion que estamos tratando es para hacer que el arranque de la tablet sea a partir de la SD y no de la NAND, es decir con toda esta historia estamos simulando lo que tiene cargada la nand de la tablet, que acaba ejecutando el u-boot y este uboot de la nand es el que arranca de la misma nand o va a buscar a la SD un script de u-boot, que actualmente se utiliza para flashear la nand.
Necesitamos una manera de que la tablet arranque de la SD, lo que aparece al princio de la pagina con unos switches, necesitamos simular esos switches en la tablet para que Arranque el uboot de la SD.
Lo que hacemos ahora pulsando (-) y power no lo simula, ya que si fuera así no bastaria con copiar unos ficheros en fat32 para flashear. Lo que hace esa pulsacion es que el u-boot de la nand ejecute el script que esta en la sd.

Uff vaya royo he soltado... y lo peor es que no se si me he explicado...

[STEVE_MARS]

Te has explicado perfectamente, de hecho creo que ya se donde esta el error: he ejecutado el script con la SD formateada en FAT32 sin hacer ningun tipo de particion, e imagino que antes habra que particionarla con las que correspondan.
Me pongo a revisarlo, pero al menos ya tenemos todos los ficheros gracias a cpro, que el tio se los ha currado y me los ha mandado por mail.
Gracias a todos por el esfuerzo y el interes. Como consigamos solucionar esto hacemos quedada de chuletas y sangria, que cojones X-D.

[beachsun]

A mi me sigue quedando la duda de como hacer que arranque el uboot de la SD.

Ojo, no digo hacer que arranque el uscript de la SD, que eso lo hace pulsando (-) y Power. Quizas con (+) + (-) + Power como dicen en tabletrepublic?

Por otro lado todavia nos queda el cartucho de arrancar un android desde la SD encenciendo con el (-) pulsado...

[exxtrema]

Te has explicado perfectamente, de hecho creo que ya se donde esta el error: he ejecutado el script con la SD formateada en FAT32 sin hacer ningun tipo de particion, e imagino que antes habra que particionarla con las que correspondan.
Me pongo a revisarlo, pero al menos ya tenemos todos los ficheros gracias a cpro, que el tio se los ha currado y me los ha mandado por mail.
Gracias a todos por el esfuerzo y el interes. Como consigamos solucionar esto hacemos quedada de chuletas y sangria, que cojones X-D.

a esto me apunto jejjejje

[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.

Para que arranque la Voyo, si lo hace desde la SD, como creo haber entendido que sugiere ese post del (+) (-) (Pow), no hacen falta switches: con ellos se configura el dispositivo de inicio en la Arndale. Lo importante de estos archivos es que, si arranca desde la SD, podrían arreglar un cacharro "voyado" (que aún se encienda) aplicando el "utscript" desde la "trust zone" (¿por USB?).

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.

[beachsun]

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.

Si te refieres a la referencia a tu mSD, es correcto he hecho, erroneamente, la comparacion de Bytes contra bloques de 512 Bytes...
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).

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.
Esto lo leo luego con calma que me he perdido... :)

[cpro]

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...


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.


No tengo muy claro que es la TrustZone.


Tampoco lo tengo muy claro pero creo que es el software de Samsung que permite utilizar "fastboot", pero es sólo una conjetura mía.


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... :)

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í ;-)

[beachsun]

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.
La verdad es que estoy un poc oxidado en todo esto... pero, no te molestes, pero sigue sin cuadrarme.

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
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
La unidad en esta SD es de 512 bytes.
No veo porque el primer bloque de tu particion no puede ser el 1. El primer cilindro que comentas seria el Bloque 0.

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í ;-)Cierto si no esta en la primera particion FAT no deberia hacer nada mas que arrancar de la SD.


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/ubuntu/boards/arndale/arndale-raring_server_20130723-408.img.gz
el resto de ficheros : http://releases.linaro.org/latest/ubuntu/boards/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... :)

[beachsun]

Aqui la tabla de particiones de la imagen de SD comentada(realmente de los dos primeros megas del fichero) :
http://img826.imageshack.us/img826/8805/1o31.png (http://imageshack.us/photo/my-images/826/1o31.png/)

[teredur]

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?

[beachsun]

Supongo que para verlo habra que sacarlo con un dd if=/dev/block/mmcblk0 of=EresElBoot count=16065*9 ...
Alguien con la tablet?

[STEVE_MARS]

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?

[beachsun]

Lo que comentaba era intentando responder a la pregunta de 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?

Que para saberlo habría que extraerlos con un DD por ejemplo y partir de ahí revisarlo.

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.

[STEVE_MARS]

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.

[cpro]

¡Qué bueno es esto de aburrirse! :grin: 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.
b.- Si no copia los 512B iniciales... es una imagen tomada de una tarjeta de memoria en la que está eliminando el sector de arranque.
c.- Salida de fdisk aplicado al fichero:
Disk bootloader_sd.vhd: 1 MB, 1048576 bytes, 2048 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
bootloader_sd.vhd1 1722996 7708139 2992572 c W95 FAT32 (LBA)
bootloader_sd.vhd2 68013 279608 105798 83 Linux
bootloader_sd.vhd3 279609 1307360 513876 83 Linux
bootloader_sd.vhd4 1307361 1722995 207817+ 83 Linux

Las entradas de la tabla de particiones no están en el orden del disco
d.- El fichero ocupa 1MB y todo parece indicar que es el primero de una memoria de 4GB. Además, fdisk debe de reservar algo más de 33MB (bloque 68013) para los cargadores.
e.- En cuanto al 0x800, me da por pensar que las unidades son KB (2MB), aunque podrían ser de 512B (1MB).
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.
b.- El 407 no me cuadra, salvo que se estuviera cargando lo que ha copiado antes: si yo hiciera una tarjeta con este esquema, no lo copiaría.
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 = 2MB
b.- El archivo ocupa 188.3KB
8.- Copia el logo de Voyo (en el espacio de logo).
a.- Es un BMP 480x480
b.- Ocupa 691.3KB
c.- Le proporciona un espacio de 4MB
9.- Hace lo mismo con el los de carga "bootres"
a.- Es un BMP de 260x125 que ocupa 1MB
b.- Es curiso porque lo hace con los valores 100000 11: ¿lo copia despues de los 4MB del anterior y le da 1MB?¿Lo copia en la dirección 1MB de espacio de logo?¿Qué es el 11? ¿Acaso copia 11 bloques de un mega (0x100000) después del de 4MB?
10.- 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?

[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.

[cpro]

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.

No hay preguntas tontas.

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.

[beachsun]

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

[STEVE_MARS]

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? X-D

[STEVE_MARS]

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:
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


¿Que os parece?

[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.

[cpro]

¿Que os parece?

Más o menos lo mismo: quitaría también todo lo que está en cursiva y "fatformat mmc 0:1", pero no el ramdisk. El "rescan", en principio, es por hacer el fdisk: se hacen los dos o ninguno. Lo que me doy cuenta ahora es que para la cache lo único que hace es crear la partición de nuevo ¿sabes hacer ese "whipe"?

Pero las aplicaciones instaladas las perderías siempre que reemplazaras "system.img" y "userdata.img", si no me equivoco.

[cpro]

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.

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 encenderia si arrancara desde la SD.

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

Me haces dudar: he dado por supuesto que el controlador DMA copia directamente de una memoria a la otra, sin pasar por RAM. Seguramente, tienes razón.

[teredur]

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.

Estoy de acuerdo y modificaria el final para que se apagara sola, como ahora.
Aunque no particionamos el user data a 2Gb.

utsetbacklight 0
shut 1
reset

sleep 1000

[beachsun]

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.
Estoy de acuerdo, uno de los objetivos debe ser el poder arrancar la tablet con el "boot" corrupto arrancando en modo BootSD y con un SD preparada. Pero quizas antes deberíamos confirmar si el modo BootSD se activa con (+)(-)(Pow).
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...

[STEVE_MARS]

Bueno, pues con lo que sabemos, ¿os parece si recapitulamos y empezamos a hacer pruebas reales?
Podiamos crear un hangout por Google Talk y ponernos de acuerdo una tarde que los cuatro podamos (teredur, beachsun, cpro y un servidor) y poner los mismos parametros entre todos.
¿Lo veis bien?

[beachsun]

Yo por mi parte no tengo problema en ayudar en lo que pueda aportar... Únicamente comentar que estoy un poco limitado ya que no tengo Tablet, y mi entorno Linux es una máquina virtual justita de espacio y memoria, por lo que no puedo (al menos facilmente) por el momento hacer cosas como compilar.

[cpro]

Por mi bien, pero vivo en modo tecla: ni siquiera tengo micro. Ni voyo.

No obstante, steve, ¿has podido comprobar si arranca de la SD? En teoría (o eso crei entender), con los archivos de la Arndale, si arranca, deberías tener acceso por el USB (/dev/ttyUSB0) a través de minicom. Pone que le cuesta unos 10 segundo y que si usas cualquier tecla en 3, entra en modo u-boot.

[beachsun]

Coñe eso es interesante... no he visto que los ficheros de arndale escupan el terminal por el USB, pero no dejar de ser interesante...

[cpro]

Coñe eso es interesante... no he visto que los ficheros de arndale escupan el terminal por el USB, pero no dejar de ser interesante...

No lo pone pero yo tengo mucha imaginación :ok: Creo que es lo único factible, más si cabe cuando el chino me insistía por chat en si el ordenador reconocía el palimpsesto: si ni siquiera se me encendía, qué va a reconocer... aunque ahora me gustaría tenerlo aquí para probar cosas. :cry: Y el ruso que dice que lo ha hecho, si no nos engaña, ¿cómo lo ha podido hacer si no es así? Aunque pienso que si puede arrancar de la SD, no debería hacer falta darle a ningún botón.

Además, si entra en modo u-boot, poniendo "help comando" deberíamos tener la información de qué hace cada comando del utscript; eso, si lo que he encontrado por ahí es cierto y no he localizado nada del Exynos.

PD.: para ver si lo monta, en linux se puede ver con el comando "dmesg" y si se quiere ver lo que va haciendo... comando "tail -f /var/log/dmesg" (creo que eso funciona incluso en Ubuntu, pero no lo he usado nunca). Debería aparecer algo parecido a ttyUSB0.

[STEVE_MARS]

No he conseguido particionarla. Si formateo en FAT y despues me voy a Linux, el proceso lo hace correcto, incluso se ve en el led como va grabando (o al menos accediendo) en la SD. Pero despues la SD esta vacia, no tiene nada.
Edito: he posteado antes de leer tu ultimo post, pruebo a coger un log de lo que hace.

[cpro]

No he conseguido particionarla. Si formateo en FAT y despues me voy a Linux, el proceso lo hace correcto, incluso se ve en el led como va grabando (o al menos accediendo) en la SD. Pero despues la SD esta vacia, no tiene nada.
Edito: he posteado antes de leer tu ultimo post, pruebo a coger un log de lo que hace.

De todos modos, eso de que está vacía... si se la metes a Windows, ¿quiere formatearla de nuevo?

[beachsun]

Steve, lo que intentas es el script de tu post 28 : http://www.htcmania.com/showpost.php?p=9660691&postcount=28 ?
Si es así el script NO copia ficheros en el FS FAT, es decir no los vas a ver ni en Windows ni en Linux... ya que no escribe los ficheros, sino lo que hace es escribir los datos de los ficheros a pelo en unas posiciones fijas de la SD.
Pueden pasar dos cosas :
- Que donde se escriba este en un hueco sin uso antes de la primera particion -> si la tenias en fat, sigues teniendo una SD en fat sin ficheros.
- Que donde se escriba, te machaque los datos de la FAT -> Fs corrupto y probablemente no te lo reconozca el Windows.

Que no veas los ficheros no quiere decir que no esten guardados...
Por ejemplo desde linux haz un dd de la SD desde el byte 0x00200 hasta el byte 0x03DFF, el fichero resultante debe ser el mismo que
exynos5250.bl1.bin

Pruebalo y nos cuentas...

[STEVE_MARS]

Os cuento:
Formateo en el PC la microsd, y la paso al portatil con Ubuntu.
Ejecuto el script y se supone que lo hace todo correcto, este es el log:

alex@alex-Presario-V4000-EK998EA-ABE:~$ cd sd_voyo
alex@alex-Presario-V4000-EK998EA-ABE:~/sd_voyo$ cd cpro
alex@alex-Presario-V4000-EK998EA-ABE:~/sd_voyo/cpro$ ./mksd.sh /dev/mmcblk0

STEP 1. check device
brw-rw---- 1 root disk 179, 0 ago 1 20:59 /dev/mmcblk0

STEP 2. confirm device
continue ()? [Y/n]: y

STEP 3. check file
-rw-r--r-- 1 alex alex 15360 jul 31 15:29 /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/exynos5250.bl1.bin
-rw-r--r-- 1 alex alex 14336 jul 31 15:30 /home/alex/sd_voyo/cpro/u-boot/bl2.bin
-rw-r--r-- 1 alex alex 256428 jul 31 15:29 /home/alex/sd_voyo/cpro/u-boot/u-boot.bin
-rw-r--r-- 1 alex alex 94208 jul 31 15:29 /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/exynos5250.tzsw.bin

STEP 4. unmounting partitions

STEP 5. clean up boot area
[sudo] password for alex:
32+0 registros leídos
32+0 registros escritos
16384 bytes (16 kB) copiados, 0,00658855 s, 2,5 MB/s

STEP 6. copy/fusing files
30+0 registros leídos
30+0 registros escritos
15360 bytes (15 kB) copiados, 1,00445 s, 15,3 kB/s
28+0 registros leídos
28+0 registros escritos
14336 bytes (14 kB) copiados, 0,0896348 s, 160 kB/s
500+1 registros leídos
500+1 registros escritos
256428 bytes (256 kB) copiados, 1,93361 s, 133 kB/s
184+0 registros leídos
184+0 registros escritos
94208 bytes (94 kB) copiados, 0,72893 s, 129 kB/s
STEP 6. Completed.
Fuse time = 11 sec.
alex@alex-Presario-V4000-EK998EA-ABE:~/sd_voyo/cpro$

Luego paso el dmesg y me da este log:

[ 682.968066] tifm_core: MMC/SD card detected in socket 0:3
[ 683.232457] mmc3: new SD card at address b368
[ 683.238098] mmcblk0: mmc3:b368 UD 968 MiB
[ 683.242972] mmcblk0: p1
[ 806.722094] tifm0 : demand removing card from socket 0:3
[ 806.722163] mmc3: card b368 removed
[ 806.723653] mmcblk0: error -123 sending status command, retrying
[ 806.723663] mmcblk0: error -123 sending status command, retrying
[ 806.723671] mmcblk0: error -123 sending status command, aborting
[ 806.723679] end_request: I/O error, dev mmcblk0, sector 1024
[ 806.723687] quiet_error: 42 callbacks suppressed
[ 806.723694] Buffer I/O error on device mmcblk0, logical block 128
[ 806.723700] lost page write due to I/O error on mmcblk0
[ 806.723712] end_request: I/O error, dev mmcblk0, sector 1032
[ 806.723719] Buffer I/O error on device mmcblk0, logical block 129
[ 806.723725] lost page write due to I/O error on mmcblk0
[ 806.723732] end_request: I/O error, dev mmcblk0, sector 1040
[ 806.723738] Buffer I/O error on device mmcblk0, logical block 130
[ 806.723744] lost page write due to I/O error on mmcblk0
[ 806.723751] end_request: I/O error, dev mmcblk0, sector 1048
[ 806.723757] Buffer I/O error on device mmcblk0, logical block 131
[ 806.723763] lost page write due to I/O error on mmcblk0
[ 806.723770] end_request: I/O error, dev mmcblk0, sector 1056
[ 806.723776] Buffer I/O error on device mmcblk0, logical block 132
[ 806.723782] lost page write due to I/O error on mmcblk0
[ 849.260059] tifm_core: MMC/SD card detected in socket 0:3
[ 849.476462] mmc3: new SD card at address b368
[ 849.482089] mmcblk0: mmc3:b368 UD 968 MiB
[ 849.486962] mmcblk0: p1

Antes mandaba el script a mmcblk0p1, ahora he cambiado a mmcblk0, lo he mirado con fdisk -l.
Y ahora, con blk0, sí me pide formaterar al meterla en el PC, lo cual siginifica que el formato ha cambiado. Pero si la meto en Ubuntu, no la reconoce aunque con fdisk -l me sigue apareciendo.
Antes con blk01p la ponian en windows la reconocia y me decia que estaba vacia.

He probado a arrancar con power, vol- y reset y no hace nada.
y con vol-, vol+ y power tampoco, arranca normal.

[STEVE_MARS]

Steve, lo que intentas es el script de tu post 28 : http://www.htcmania.com/showpost.php?p=9660691&postcount=28 ?
Si es así el script NO copia ficheros en el FS FAT, es decir no los vas a ver ni en Windows ni en Linux... ya que no escribe los ficheros, sino lo que hace es escribir los datos de los ficheros a pelo en unas posiciones fijas de la SD.
Pueden pasar dos cosas :
- Que donde se escriba este en un hueco sin uso antes de la primera particion -> si la tenias en fat, sigues teniendo una SD en fat sin ficheros.
- Que donde se escriba, te machaque los datos de la FAT -> Fs corrupto y probablemente no te lo reconozca el Windows.

Que no veas los ficheros no quiere decir que no esten guardados...
Por ejemplo desde linux haz un dd de la SD desde el byte 0x00200 hasta el byte 0x03DFF, el fichero resultante debe ser el mismo que
exynos5250.bl1.bin

Pruebalo y nos cuentas...

Dame el comando exacto del dd que me pierdo X-D

[beachsun]

La segunda ejecucion es la correcta, es decir el scrip se lanza contra el dispositivo, no contra una particion.
El comando seria algo como :
dd iflag=dsync oflag=dsync if=/dev/mmcblk0 of=/home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/Copia-exynos5250.bl1.bin bs=512 skip=1 count=30

Esto te deberia generar un fichero Copia-exynos5250.bl1.bin igual que /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/exynos5250.bl1.bin , pero leido de la SD.
Si son iguales, que no lo dudo, tenemos el arranque, pero como decia faltan dos cosas :
- Saber como hacer que la Tablet arranque de esos ficheros -> Segun whiterussian con (+)(-)(Pow)
- Saber como arrancan esos fichero y que mas necesitan... es decir probablemente se necesite un kernel que no hemos puesto, un root para arrancar...

Creo que es muy necesario un serial/consola... necesitamos ver que pasa, si ha pillado ese arranque o hacer el arranque normal.

Vamos a Jugar con lo que tenemos.
Si son iguales y suponemos que la SD esta OK, yo probaria arrancar la tablet con/sin la SD puesta:
- (Pow) -> Normal
- (-)(Pow)
- (+)(-)(Pow)
No se si introducir la variante del Reset.
Quiero decir que la SD no flashea, ya que es un intento de arranque, por lo que es "segura", pero no se que hace exactamente el Reset... supongo que no borra nada, pero ....

Como digo probaria arrancar varias veces con las combinaciones y estar atento a :
- Comportamiento
- Tiempo de cada cambio : por ejemplo esta 1 segundo enciende el led, 2s despues enciende el lcd...

El tema es poder comparar cada arranque con un arranque normal sin la SD. La idea es intentar detectar si alguno de los arranques con la SD ha sido distinto en algo al resto o al mismo arranque sin sd... es decir si avanzaba algo...

PD : el Whiterussian este de Tabletrepublic, solo ha aparecido para soltar la perla y no ha vuelto a aparecer... me parece muuu raro... Firmado : Uno que es mal Pensado... :)

[rivermon]

Menuda currada amigos, esto con nada os lo podemos agradecer,
NO HAGAS NADA PARA QUE TE LO AGRADEZCAN, PERO TRATA DE HACERLO PARA GENTE AGRADECIDA


Muchas gracias a todos por esta entrega gratuita de conocimientos y esta currada tan enorme

:gracias: :gracias: :gracias: :gracias:

[STEVE_MARS]

el Whiterussian este de Tabletrepublic, solo ha aparecido para soltar la perla y no ha vuelto a aparecer... me parece muuu raro... Firmado : Uno que es mal Pensado... :)

Has sido el primero en decirlo pero no en pensarlo, jejejjejeeeeeee.
De todas formas una cosa sí ha hecho: abrirnos una ventana curtural y no apedrear los cristales, como dicen los compadres X-DX-DX-DX-D

[STEVE_MARS]

Hay que descartar el power y vol+, intenta entar en Recovery y como lo no encuentra hace un wipe data, vamos, que el tablet esta como recien instalado.
Cosa que por otro lado, es raro... si no tiene recovery.img, ¿como co..ones hace un wipe data?. Tiene que tener algo para que ejecute esa orden, tan listo no es como para hacerlo él solito.

[beachsun]

A bueno si nos "a habierto una ventana curtural" entonces nada... retiro lo dicho ;)

[beachsun]

A ver si me aclaro...
Para Actualizar : (-)(Pow)
Para Recovery : (+)(Pow)
Correcto?
Que hace el recovery?
que te muestra?
es texto o grafico?
Que textos Muestra...

Pasata un video anda... :)

[beachsun]

Me tendras que perdonar, pero a que llamas hacer un "wipe data"?
No puede ser que lo que haga simplemente es formatear la particion data y el resultado sea al mismo?

[cpro]

Es normal que después de hacer el "mksdcard" linux no reconozca tarjeta hasta que no la saques y la vuelvas a meter: has modificado su información. La salida que te proporciona el script es correcta. En teoría, si metes esa tarjeta en la Voyo, debería hacer algo, si arranca de la SD.

Lo del dmesg es para lo siguente:
Opcional (si no quieres usar minicom con sudo)
1.- Conectas la Voyo (apagada) por USB al ordenador con Linux.
2.- En un terminal, escribes el "tail -f /var/log/dmesg"
3.- Enciendes la Voyo y obtienes el VendorID y ProductID
4.- Puedes apagar/desconectar la Voyo
5.- Añades esos valores como dice en "Configuring USB access" en la página de Arndale

Si no quieres hacer lo anterior usas minicom con sudo
1.- Conectas la Voyo (apagada) por USB al ordenador con Linux.
2.- En un terminal, escribes el "tail -f /var/log/dmesg"
3.- Configuras el minicom como dice en la página de Arndale "Setting serial port" (115200bps...) usando como puerto de comunicación /dev/ttyUSB0
4.- Enciendes la Voyo con la tarjeta SD puesta y probando si arranca desde la tarjeta; o con la combinación (+) (-) (Pow)
5.- Si arranca, en la terminal que está ejecutando el "dmesg" deberá aparecerte que la ha reconocido y que habilita el ttyUSB0
6.- El minicom debería poder conectarse y convertirse en terminal de la Voyo.

Que escribís mucho!!! Más me valía haberme puesto a ver una peli :palomitas:

Lo del ruso... en fin.

[STEVE_MARS]

A ver si me aclaro...
Para Actualizar : (-)(Pow)
Para Recovery : (+)(Pow)
Correcto?
Que hace el recovery?
que te muestra?
es texto o grafico?
Que textos Muestra...

Pasata un video anda... :)

No hace nada, no sale texto ni graficos...nada. Se enciende, tarda un poco mas en arrancar (buscado el recovery imagino) y despues arranca como si acabaras de instalarla.

[STEVE_MARS]

Me tendras que perdonar, pero a que llamas hacer un "wipe data"?
No puede ser que lo que haga simplemente es formatear la particion data y el resultado sea al mismo?

Si, es lo mismo. En los CWM ó TWRP Recovery lo llamamos wipe data.
El caso es que si formatea la particion data quiere decir que hay algo en el recovery.
Ni imaginais lo importante que seria obtener el recovery.img. De ahí scariamos el kernel del recovery y el recovery.fstab, y de ahi al CWM Recovery es coser y cantar... habitualmente, claro.

[STEVE_MARS]

dd iflag=dsync oflag=dsync if=/dev/mmcblk0 of=/home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/Copia-exynos5250.bl1.bin bs=512 skip=1 count=30Me da error, permiso denegado a dev/mmcblk0.

Y por cierto, aunque saque y vuelva a meter la SD sigue sin reconocerla Ubuntu.
Ahora pruebo la conexion por USB a Linux :ok:

[cpro]

Con respecto a lo del recovery... igual es porque como lo miro con el "hexdump", que no sé cómo extraerlo, pero después de apagar la máquina, el "utscript" pone algo que parece hacer referencia a código de depuración, si encuentra un zImage.debug, aunque no lo sé seguro si es eso y fija algunas variables como la consola, velocidad...

No tenemos un kernel con código de depuración, creo, pero si metes el normal con ese nombre puede que también (que no lo sé) se conecte por consola al minicom y vuelque allí la información del núcleo. También pone a continuación algo de "...check the recovery zImage.debug"

[cpro]

Y por cierto, aunque saque y vuelva a meter la SD sigue sin reconocerla Ubuntu.
Ahora pruebo la conexion por USB a Linux :ok:

Por lo que veo la tarjeta que usas es de 1GB. Comprueba con fdisk, una vez formateada, si el bloque de inicio de la partición es mayor o igual que 1047, suponiendo que los bloques son de 512B.

[STEVE_MARS]

dmesg -f /var/log/todo
me da dmesg: unknown facility '/var/log/todo'

¿que hago?

[cpro]

dmesg -f /var/log/todo
me da dmesg: unknown facility '/var/log/todo'

¿que hago?

Se me ha ido :loco:

Es que yo suelo ponerme ese archivo como log de todo... Lo que has de escribir es:

tail -f /var/log/dmesg

Pido disculpas
PD.: Cuando quieras quitarlo... <Ctrl>+<c>

[beachsun]

dd iflag=dsync oflag=dsync if=/dev/mmcblk0 of=/home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/Copia-exynos5250.bl1.bin bs=512 skip=1 count=30Me da error, permiso denegado a dev/mmcblk0.
Correcti, me olvide sudo delante del todo...
Es decir sudo dd .......


Y por cierto, aunque saque y vuelva a meter la SD sigue sin reconocerla Ubuntu.
Ahora pruebo la conexion por USB a Linux :ok:
Si no te la reconoce sera porque los ficheros han machacado informacion del FS.

Las particiones que quieras que sobrevivan hay que crearlas a partir de un punto concreto en tu caso si creas una particion fat a partir de 1 (Mbr) + (30+28+500+184) (ficherosCopiados) + 5 (margen) =
748, la formateas y metes unos ficheros -> despues de pasarle el script continuara la particion completa con sus ficheros y los podras leer desde Windows/linux, etc...

[cpro]

Las particiones que quieras que sobrevivan hay que crearlas a partir de un punto concreto en tu caso si creas una particion fat a partir de 1 (Mbr) + (30+28+500+184) (ficherosCopiados) + 5 (margen) =
748

Si no he hecho mal las cuentas, el primer bloque de la partición debería ser 1049.

[beachsun]

Pues ni pa ti ni pa mi... :)

En la imagen y en la tabla de http://users.elis.ugent.be/~nipennem/arndale/ se ve que el script deja de machacar en
Space for kernel, partitions, etc. 0x84E00 544256
Es decir primer bloque (512) libre -> 544256/512 = 1063

[cpro]

El calculo que he hecho es :
Bloques de 512B que ha escrito el scrip :
STEP 6. copy/fusing files 30+0 registros leídos 30+0 registros escritos 15360 bytes (15 kB) copiados, 1,00445 s, 15,3 kB/s 28+0 registros leídos 28+0 registros escritos 14336 bytes (14 kB) copiados, 0,0896348 s, 160 kB/s 500+1 registros leídos 500+1 registros escritos 256428 bytes (256 kB) copiados, 1,93361 s, 133 kB/s 184+0 registros leídos 184+0 registros escritos 94208 bytes (94 kB) copiados, 0,72893 s, 129 kB/s

Pero esos son los tamaños de los ficheros, no el espacio que reserva:
http://www.htcmania.com/showpost.php?p=9667403&postcount=40

[STEVE_MARS]

[quote=beachsun;9683999]Correcti, me olvide sudo delante del todo...
Es decir sudo dd .......

Esto me da:
30+0 registros leídos
30+0 registros escritos
15360 bytes (15 kB) copiados, 1,33759 s, 11,5 kB/s

¿Y ahora que?
¡¡¡ lavin, como me gusta esto, es como comer pollo asado con las manos ¡¡¡ :risitas:

[beachsun]

Pero esos son los tamaños de los ficheros, no el espacio que reserva:
http://www.htcmania.com/showpost.php?p=9667403&postcount=40

Correcto mientras lo estaba editando, me has contestado, nos hemos cruzado... me has hecho revisarlo y he visto el error, pero no me sale lo mismo que a ti, me sale algo mas...

PD : Y acabo de ver porque, simplemente la suma de esa tabla que me indicas esta mal.

Bien, estamos diciendo lo mismo... :D

[beachsun]

[quote=beachsun;9683999]Correcti, me olvide sudo delante del todo...
Es decir sudo dd .......

Esto me da:
30+0 registros leídos
30+0 registros escritos
15360 bytes (15 kB) copiados, 1,33759 s, 11,5 kB/s

¿Y ahora que?
¡¡¡ lavin, como me gusta esto, es como comer pollo asado con las manos ¡¡¡ :risitas:

Simplemente hemos vuelto a leer uno de los ficheros de la SD, uno de esos que no vemos... pues esta, es para confirmar que esta.
Si quieres comparalo con el original para terminar la prueba, pero no deja de ser solo eso.

Ahora mismo me parece mas interesante ver si arranca la SD y si escupe algo por el USB....:grin:

[STEVE_MARS]

No puede ser que me lo reconozca como un Nexus S ¡¡¡

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 03f0:171d Hewlett-Packard Bluetooth 2.0 Interface [Broadcom BCM2045]
Bus 003 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 008: ID 18d1:4e22 Google Inc. Nexus S (debug)


Y es ese, porque he desconectado el USB y ya no me lo reconocia.
Lo he sacado con lsusb, al poner el dmesg:


[ 8018.512065] usb 1-5: new high-speed USB device number 5 using ehci_hcd
[ 8021.229438] scsi3 : usb-storage 1-5:1.0
[ 8021.229936] usb 1-5: USB disconnect, device number 5
[ 8032.260052] usb 1-5: new high-speed USB device number 6 using ehci_hcd
[ 8032.412063] scsi4 : usb-storage 1-5:1.0
[ 8033.412756] scsi 4:0:0:0: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8033.413236] scsi 4:0:0:1: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8033.420784] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 8033.421389] sd 4:0:0:1: Attached scsi generic sg3 type 0
[ 8033.423963] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[ 8033.426962] sd 4:0:0:1: [sdc] Attached SCSI removable disk
[ 8175.046472] usb 1-5: USB disconnect, device number 6
[ 8201.648344] hub 1-0:1.0: unable to enumerate USB device on port 5
[ 8201.944058] usb 1-5: new high-speed USB device number 8 using ehci_hcd
[ 8202.090285] scsi5 : usb-storage 1-5:1.0
[ 8203.089046] scsi 5:0:0:0: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8203.089526] scsi 5:0:0:1: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8203.096427] sd 5:0:0:0: Attached scsi generic sg2 type 0
[ 8203.096897] sd 5:0:0:1: Attached scsi generic sg3 type 0
[ 8203.103126] sd 5:0:0:0: [sdb] Attached SCSI removable disk
[ 8203.104705] sd 5:0:0:1: [sdc] Attached SCSI removable disk
[ 8260.111773] usb 1-5: USB disconnect, device number 8
[ 8387.864286] hub 1-0:1.0: unable to enumerate USB device on port 5
[ 8388.160113] usb 1-5: new high-speed USB device number 10 using ehci_hcd
[ 8388.306037] scsi6 : usb-storage 1-5:1.0
[ 8389.305432] scsi 6:0:0:0: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8389.306143] scsi 6:0:0:1: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8389.314301] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 8389.317375] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 8389.317626] sd 6:0:0:1: Attached scsi generic sg3 type 0
[ 8389.321612] sd 6:0:0:1: [sdc] Attached SCSI removable disk
[ 8416.444105] usb 1-5: USB disconnect, device number 10
[ 8443.856282] hub 1-0:1.0: unable to enumerate USB device on port 5
[ 8444.140089] usb 1-5: new high-speed USB device number 12 using ehci_hcd
[ 8444.287464] scsi7 : usb-storage 1-5:1.0
[ 8445.285839] scsi 7:0:0:0: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8445.286552] scsi 7:0:0:1: Direct-Access exynos5 File-CD Gadget 0000 PQ: 0 ANSI: 2
[ 8445.297468] sd 7:0:0:0: [sdb] Attached SCSI removable disk
[ 8445.297577] sd 7:0:0:0: Attached scsi generic sg2 type 0
[ 8445.298490] sd 7:0:0:1: Attached scsi generic sg3 type 0
[ 8445.302400] sd 7:0:0:1: [sdc] Attached SCSI removable disk
[ 8460.306538] usb 1-5: USB disconnect, device number 12

[STEVE_MARS]

Si no quieres hacer lo anterior usas minicom con sudo
1.- Conectas la Voyo (apagada) por USB al ordenador con Linux.
2.- En un terminal, escribes el "tail -f /var/log/dmesg"
3.- Configuras el minicom como dice en la página de Arndale "Setting serial port" (115200bps...) usando como puerto de comunicación /dev/ttyUSB0
4.- Enciendes la Voyo con la tarjeta SD puesta y probando si arranca desde la tarjeta; o con la combinación (+) (-) (Pow)
5.- Si arranca, en la terminal que está ejecutando el "dmesg" deberá aparecerte que la ha reconocido y que habilita el ttyUSB0
6.- El minicom debería poder conectarse y convertirse en terminal de la Voyo.


¿Como configuro el minicom para hacer mas pruebas?

[cpro]

No puede ser que me lo reconozca como un Nexus S ¡¡¡


Googleando un poco, ID 18d1:4e22, parece ser que es el genérico de los Android en modo "debug", que me parece que es sólo que están conectados por USB. Pero tampoco he buscado mucho.

[beachsun]

No te puedo ayudar, no lo he usado nunca... a ver si cpro te puede hechar una mano.

[cpro]

¿Como configuro el minicom para hacer mas pruebas?

Hace decenios (más de 1 seguro) que no lo he utilizado así que... mira a ver si esto te puede ayudar:

https://help.ubuntu.com/community/Minicom

Parece que la clave, una vez instalado, está en arrancarlo con "-s". Pero si no lo ves claro, dímelo y lo instalo.

[beachsun]

Chicos lo tengo que dejar por hoy...
A ver si para mañana ya lo teneis todo resuelto ;)

[cpro]

Esto me da:
30+0 registros leídos
30+0 registros escritos
15360 bytes (15 kB) copiados, 1,33759 s, 11,5 kB/s

¿Y ahora que?

Si has usado la línea de comando que ha puesto beachsun, escribe esto:

diff /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/exynos5250.bl1.bin /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/Copia-exynos5250.bl1.bin

Si no dice nada, todo está bien. Si no, dirá que son distintos.

[STEVE_MARS]

Un abrazo fuerte y gracias por todo, de veras :ok:

[STEVE_MARS]

Si has usado la línea de comando que ha puesto beachsun, escribe esto:

diff /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/exynos5250.bl1.bin /home/alex/sd_voyo/cpro/vendor/insignal/arndale/exynos5250/Copia-exynos5250.bl1.bin

Si no dice nada, todo está bien. Si no, dirá que son distintos.

No ha dicho nada, o sea que todo esta bien :ok:

[STEVE_MARS]

Minicom funcionando, o eso parece:

+-------------[Configuración]--------------+
| Nombres de archivos y rutas |
| Protocolos de transferencia de archivos |
| Configuración de la puerta serial |
| Modem y marcado de número |
| Pantalla y teclado |
| Salvar configuración como dfl |
| Salvar configuración como.. |
| Salir |
| Salir del Minicom |
+------------------------------------------+ He configurado el tty como USB0:

+-----------------------------------------------------------------------+
| A - Dispositivo Serial : /dev/ttyUSB0 |
| B - Localización del Archivo de Bloqueo : /var/lock |
| C - Programa de Acceso : |
| D - Programa de Salida : |
| E - Bps/Paridad/Bits : 115200 8N1 |
| F - Control de Flujo por Hardware: Sí |
| G - Control de Flujo por Software: No |
| |
| ¿Qué configuración alterar?

Al salir me dice que ttyUSB0 no existe y no lo puede abrir.

[cpro]

Minicom funcionando, o eso parece:

Ahora que debería hacer?

Quita también el "Hardware Flow Control".

La gracia de esto es que arranque con la tarjeta SD. Si lo hace, el dmesg te mostrará que crea la tty (ttyUSB0) y con eso podrías conectarte con minicom. Según la página de Arndale, si das a cualquier tecla en tres segundos, se queda en el modo u-boot y se pueden poner los comandos del utscript.

Pero lo dicho, nos basamos en la palabra de un ruso que ha puesto un mensaje en un foro y no ha vuelto a dar señales de vida :silbando:

[spektro]

Pero lo dicho, nos basamos en la palabra de un ruso que ha puesto un mensaje en un foro y no ha vuelto a dar señales de vida :silbando:

Me encanta esta frase.

Suerte con los experimentos!

[teredur]

Como avanzais,..
Aclarandome:
- 1º premisa para que uboot pueda leer los ficheros de la SD, deben tener un particionado valido.
-2º para poder meter los ficheros de boot, flw1,tzw, uboot , etc, se empieza a particionar la sd por encima del sector block 0, dependiendo del tamaño bloque.
3º se inicia em modo bootSD con (+)(-)(pow)?

creo que con un fdisk -l /dev/(donde ese conectada la sd) , se deberian poder comprobar el punto 1 y 2, tal como se ha comprobado anteriormente si que estan los ficheros de boot.

Por ultimo el modo bootSD, creo que hasta aqui hemos llegado, tengo una mala experiencia con una smarTQ, donde no consegui arrancar con bootsd y eso que me pasaron la imagen de la sd de una tablet con el mismo SOC

Espero que no sea así.:cry:

[STEVE_MARS]

Buenos dias, compañeros.



alex@alex-Presario-V4000-EK998EA-ABE:~$ sudo fdisk -l /dev/mmcblk0

Disco /dev/mmcblk0: 1015 MB, 1015021568 bytes
12 cabezas, 43 sectores/pista, 3841 cilindros, 1982464 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador del disco: 0x00000000

Dispositivo Inicio Comienzo Fin Bloques Id Sistema
/dev/mmcblk0p1 251 1982463 991106+ 6 FAT16

Ayer hice pruebas con todas las combinaciones posibles, y no arranco nunca en modo bootSD.
Solo falta comprobar que los ficheros estén y que la SD este preparada para arrancar desde ella.
¿que ves con esta info, teredur?

[teredur]

Pues que me falta espacio:

STEP 6. copy/fusing files
30+0 records in
30+0 records out
15360 bytes (15 kB) copied, 1.0143 s, 15.1 kB/s
28+0 records in
28+0 records out
14336 bytes (14 kB) copied, 0.752604 s, 19.0 kB/s
500+1 records in
500+1 records out
256428 bytes (256 kB) copied, 7.08218 s, 36.2 kB/s
184+0 records in
184+0 records out
94208 bytes (94 kB) copied, 2.73305 s, 34.5 kB/s
STEP 6. Completed.
Fuse time = 14 sec.

si no he sumado mal son 742 bloques y no 250 ( -1 MBR).
Aun asi si arrancara en bootSD, se quedaria frita.

[STEVE_MARS]

¿Y alguna idea, o alguna pista?
Seria una pena tener que parar, ya que hemos llegado hasta aqui. :cry:

[cpro]

Como avanzais,..
Aclarandome:
- 1º premisa para que uboot pueda leer los ficheros de la SD, deben tener un particionado valido.


En realidad, para que arranque desde la SD, si lo hace, no necesita particionado ni nada ya que los cargadores se copian directamente en un área de la tarjeta que, en la imagen que beachsum puso de la linaro http://www.htcmania.com/showpost.php?p=9669330&postcount=44, se ve cómo está protegida por una entrada en el MBR para espacio sin sistema de archivos.


Dispositivo Inicio Comienzo Fin Bloques Id Sistema
/dev/mmcblk0p1 251 1982463 991106+ 6 FAT16

En cuanto a tu tarjeta, me temía que estaría formateada en FAT16 (es de 1GB) y sucede lo que te comentábamos sobre el bloque de inicio: es un bloque dentro de los del intervalo en que escribe los cargadores por lo que destruye la FAT de la partición.
Te me has adelantado, teredur ;-) Si miras unos pocos post antes, tienes los bloques.

He estado echando un ojo al Android y lo de las teclas... me da a mi que... porque es la configuración de entrada a "fastboot" del Nexus 10 "manta" http://source.android.com/source/building-devices.html#booting-into-fastboot-mode. Pero igual suena la flauta que... si lo tienes conectado por USB al ordenador, sin tarjeta, con una combinación o con la otra, puede que arranque en ese modo "fastboot".

[Sp4ceM4rine]

Hey guys!
Just wanted to let you know that I'm following this thread with interest.
I really appreciate all your inputs. I'm also trying to make this repair sdcard and I'll let you know if I'm able to accomplish something.
Best Regards,
Sp4ceM4rine.

From google translate X-D
Hola chicos!
Sólo quería hacerle saber que estoy siguiendo este hilo con interés.
Realmente aprecio todos sus insumos. También estoy tratando de hacer este sdcard reparación y voy a saber si soy capaz de lograr algo.
Saludos cordiales,
Sp4ceM4rine

[STEVE_MARS]

En cuanto a tu tarjeta, me temía que estaría formateada en FAT16 (es de 1GB) y sucede lo que te comentábamos sobre el bloque de inicio: es un bloque dentro de los del intervalo en que escribe los cargadores por lo que destruye la FAT de la partición.
Te me has adelantado, teredur ;-) Si miras unos pocos post antes, tienes los bloques.

He estado echando un ojo al Android y lo de las teclas... me da a mi que... porque es la configuración de entrada a "fastboot" del Nexus 10 "manta" http://source.android.com/source/building-devices.html#booting-into-fastboot-mode. Pero igual suena la flauta que... si lo tienes conectado por USB al ordenador, sin tarjeta, con una combinación o con la otra, puede que arranque en ese modo "fastboot".

Creo recordar que tambien la formateé en FAT32, pero pruebo de nuevo y os cuento.

[STEVE_MARS]

Hey guys!
Just wanted to let you know that I'm following this thread with interest.
I really appreciate all your inputs. I'm also trying to make this repair sdcard and I'll let you know if I'm able to accomplish something.
Best Regards,
Sp4ceM4rine.

From google translate X-D
Hola chicos!
Sólo quería hacerle saber que estoy siguiendo este hilo con interés.
Realmente aprecio todos sus insumos. También estoy tratando de hacer este sdcard reparación y voy a saber si soy capaz de lograr algo.
Saludos cordiales,
Sp4ceM4rine

Hi, my friend ¡¡¡¡
For all here, he´s investigated in Slatedroid forum how modify utscript :ok:.
Greetings and welcome ¡¡¡

[STEVE_MARS]

Aqui con FAT32:

alex@alex-Presario-V4000-EK998EA-ABE:~/sd_voyo/cpro$ sudo fdisk -l /dev/mmcblk0

Disco /dev/mmcblk0: 1015 MB, 1015021568 bytes
12 cabezas, 43 sectores/pista, 3841 cilindros, 1982464 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador del disco: 0x00000000

Dispositivo Inicio Comienzo Fin Bloques Id Sistema
/dev/mmcblk0p1 251 1982463 991106+ b W95 FAT32

Es exactamente igual :(

[cpro]

Es exactamente igual :(

No te preocupes por eso: lo importante era si arrancaba la tablet desde la tarjeta o no y la carga de los archivos te la hacia bien; prueba de ello es que machacaba la FAT.

¿Has podido probar mi suposición sobre el fastboot, que si la tienes conectada al ordenador entra en ese modo cuando arrancas con el (-)(Pow)?

[STEVE_MARS]

No funciona. Incluso haciendolo por adb, con adb reboot bootloader por terminal emulator me dice "device not found".

[cpro]

No funciona. Incluso haciendolo por adb, con adb reboot bootloader por terminal emulator me dice "device not found".

Me he quedado sin ideas :(
...por ahora ;-)

[cpro]

Hey guys!

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
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
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
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.
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.

[STEVE_MARS]

Me he quedado sin ideas :(
...por ahora ;-)

Creo que deberiamos aparcar este metodo y centrarnos ahora en crear un recovery simple con el github de namko, ¿lo veis viable?

[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 " "
sleep 1000

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

[cpro]

Creo que deberiamos aparcar este metodo y centrarnos ahora en crear un recovery simple con el github de namko, ¿lo veis viable?

En lo que se pueda echar una mano... encantado, pero que yo de Android ando pez, que hasta el lunes sólo lo había visto en los teléfonos que lleva la gente.

[cpro]

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]

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]

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]

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]

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]

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]

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
dd if=/dev/zero of=newuser.raw bs=1M count=2048Previous command creates a file that contains 2048MB = 2GB (showed in File system as 2.1GB) zeros
Format it using ext4
mkfs.ext4 newuser.rawIt will warning you about it is not a block device. Continue.
Mount it on your system. For example, creating a directory "new" and executing
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.
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]

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]

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 :

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 :
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]

El tema del TrustZone despejado :
http://en.wikipedia.org/wiki/ARM_architecture#Security_Extensions_.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 (http://en.wikipedia.org/wiki/System-on-a-chip), 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 (http://www.tl-mobility.com/)), allowing much tighter digital rights management (http://en.wikipedia.org/wiki/Digital_rights_management) for controlling the use of media on ARM-based devices,[/URL] 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. (http://en.wikipedia.org/wiki/ARM_architecture#cite_note-46) Open Virtualization is an open source implementation of the trusted world architecture for TrustZone.[URL="http://en.wikipedia.org/wiki/ARM_architecture#cite_note-49"] (http://en.wikipedia.org/wiki/ARM_architecture#cite_note-48)
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]

He estado revisando la forma de arrancar para instalar el recovery que namko compilo para otros tablets de urbetter y el utscript hace esto:
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]

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]

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

[STEVE_MARS]

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

[cpro]

He estado revisando la forma de arrancar para instalar el recovery que namko compilo para otros tablets de urbetter y el utscript hace esto:
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:
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]

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]

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:


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 :ok:

[beachsun]

¿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.

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 :

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.

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 :
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]

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]

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

Entiendo que lo que dices es que al rrancar con (-)(Pow) se ejcuta esto :
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 :
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?

[jolocotroco]

Lo puedes leer del bootloader_sd.vhd con un editor hex

[jolocotroco]

Esta en bootloader_sd.vhr abierto con editor hex.

Pero mirando el fichero misc:

baudrate=115200
bootcmd=setddrV 5;movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 41000000
bootdelay=1
serialno=ExynosMID
update=mmc rescan 1;fatload mmc 1 40000000 utscript_1st;source 40000000;
test10=dnw 40008000;emmc open 0;mmc write 0 0x40008200 0x0 0x800;emmc close 0
test11=dnw 40008000;emmc open 1;mmc write 1 0x40008200 0x0 0x800;emmc close 1
test2=dnw 40008000;movi read rootfs 0 41000000 100000;bootm 40008000 41000000
test3=dnw 40008000;dnw 40d00000;bootm 40008000 40d00000
bootargs=ddr=33 tmu=no macID= dock= tp=ft54 umsvor= umspct= battery=DF0C batcap= batrdc= plug= bltype=p utmodel=s1101 lcd=b116h came=500W_D_V01 codec=wm8978 bt=gb86210 wifi=gb86210 gps=no eth=dongle fm=no gsmd=no nfc= ls= motor=no lcdRGB= oem= E
ver=JB
lcd=b116h
pcb=
man=
utmodel=s1101
ddr=33
bltype=p

"bootcmd=setddrV 5;movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm"
Parece que aqui no se ejecuta utscript_1st, parece que si no se encuentra misc o esta corrupto el bootloader si ejecuta utscript_1st.

[STEVE_MARS]

Muchas gracias por tu ayuda, jolo :aplausos:
En Slatedroid ya hemos conseguido el script para formatear la particion data con 2 gb., pero lo interesante es que si el tamaño de los utscript es menor a 64 kb. no arranca desde la SD.

Por otro lado, no encuentro el tuto para crear el .vhr, dame un link concreto, por favor :campeon:.
Gracias de nuevo, maestro. Tu ayuda es muy apreciada.

[STEVE_MARS]

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).



Perfecto, ya he creado el hilo a modo de resumen de todo el desarrollo, lo he metido dentro del subforo de desarrollo, que es donde deberia haberlo abierto inicialmente.
Como siempre, muchas gracias por la currada, compañeros :ok::aplausos:.

[jolocotroco]

Busca en google " INand_mm_sd_mbr.vhd" es el .vhd que usa la dropad, hay muchas entradas.

[STEVE_MARS]

Busca en google " INand_mm_sd_mbr.vhd" es el .vhd que usa la dropad, hay muchas entradas.

Ok, antes habia leido .vhr y me estaba haciendo la picha un lio :-).

[STEVE_MARS]

Hay mil hilos donde habla de usar el .vhd para resucitar el tablet, incluso explican como crear las particiones en la SD para hacerlo.
Pero no encuentro un tuto para crear el INand_mm_sd_mbr.vhd, imagino que partiendo desde el bootloader_sd.vhd.

[STEVE_MARS]

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.:-)

Es escuchar CWM y se me pone la piel de pollo X-D.
Poooorfa, dame los primeros pasos para intentar compilar un Recovery.
Si flaseamos desde update.zip eliminamos la posibilidad de brickeos, ¿correcto?

[teredur]

El archivo utsript original, al final (enlazo con lo que puso teredur), contiene esto:
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. ;-)
Lo he robado esta noche. Arranca el update, muestra el mensaje, letras naranjas, se va a negro ......
También me he creado la SD de recuperación, con una SD de 4 Gb, deja el suficiente espacio para meter los archivos de boot, pero no consigo que arranque, he probado todas las combinaciones de teclas que se me han ocurrido...

[cpro]

Lo he robado esta noche. Arranca el update, muestra el mensaje, letras naranjas, se va a negro ......


Si no te es inconveniente, ¿puedes probar a hacerlo conectado al ordenador? A ver si dmesg dice algo.

[cpro]

Como la primera actualización que hubo fue la del 18 de junio y se produjeron los bricks, se me ha ocurrido mirar si habían cambiado algo en la del día 25: el utscript (del 18) no borra nada, ni invoca a fdisk... carga el entorno y pasa a copiar zImage, aunque sí formatea las particiones.

Con lo que estamos viendo... yo diría: quienes tengan brick, que renombren el archivo "utscript" a "utscript.bck" y el archivo "utscript_1st" a "utscript". Después, que realicen el proceso habitual.

Por otro lado, spemall, que ya tiene mi palimpsesto, insiste en que es un problema de software, por lo que le he preguntado si existe un procedimiento que yo hubiera podido seguir aquí para revivirla: sigo esperando respuesta (y aseguro que volveré a preguntarle si no me responde).

[jolocotroco]

Para actualizar sin riesgos:

source 0x41000000
utupdateenv
utsetbacklight 1
uttext 20 30 "**********************************************"
uttext 20 40 "* Exynos5 upgrade JB2 V0.1[utscript]"
uttext 20 50 "**********************************************"
uttext 20 60 " "

uttext 20 70 "Update system...Wait some minutes."
movi init 0
sleep 50

ext4format mmc 0:3
ext4format mmc 0:4
sleep 50

fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000
uttext 20 80 "OK, Update End !"

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

utsetbacklight 0
shut 1
reset

No se necesita nada mas, si hay alguna actualizacion con cambios en ramdisk, kernel o se quiere modificar las particiones, se añaden mas cosas, pero en principio los cambios principales para una rom modificada de la oficial son en system.img.
Si hay cualquier problema se puede volver al system.img anterior.

[STEVE_MARS]

Con lo que estamos viendo... yo diría: quienes tengan brick, que renombren el archivo "utscript" a "utscript.bck" y el archivo "utscript_1st" a "utscript". Después, que realicen el proceso habitual.


Probado por un compañero y no hace nada, ni siquiera arranca :cry:

[cpro]

Probado por un compañero y no hace nada, ni siquiera arranca :cry:

Gracias. Sería bueno saber si es de las que se encendían o de las que no, aunque entiendo que es de las segundas, con lo que seguiríamos con la duda de si es el botón, que no hace contacto.

[beachsun]

Para actualizar sin riesgos:

source 0x41000000
utupdateenv
utsetbacklight 1
uttext 20 30 "**********************************************"
uttext 20 40 "* Exynos5 upgrade JB2 V0.1[utscript]"
uttext 20 50 "**********************************************"
uttext 20 60 " "

uttext 20 70 "Update system...Wait some minutes."
movi init 0
sleep 50

ext4format mmc 0:3
ext4format mmc 0:4
sleep 50

fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000
uttext 20 80 "OK, Update End !"

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

utsetbacklight 0
shut 1
reset

No se necesita nada mas, si hay alguna actualizacion con cambios en ramdisk, kernel o se quiere modificar las particiones, se añaden mas cosas, pero en principio los cambios principales para una rom modificada de la oficial son en system.img.
Si hay cualquier problema se puede volver al system.img anterior.

Creo que te falta, o bien añadir la primera linea :
fatload mmc 1 0x41000000 set_bootargs

O bien quitar estas dos :
source 0x41000000
utupdateenv


Esto :
movi init 0
sleep 50
No se hasta que punto es necesario hacer un Init a la eMMC si no se ha grabado nada, piensa que en el original antes de esa linea se habia grabado todo en la eMMC.
Porque lo has dejado?

Estos formats :

ext4format mmc 0:3
ext4format mmc 0:4
Que dos particiones formatea? System y UserData?

Respecto a que basta flashear el System... ni idea... como se decia en un programa de hace años...

... lo que diga la Ruuubia... :risitas:

[beachsun]

Por lo que he visto durante las actualizaciones. y tengo grabada una en video.
EL script que se ejecuta es el utscript.
Ya que el texto mostrado es el de los comanods uttext.
Me puedes pasar alguno de esos videos?

[beachsun]

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.

Me temo que en nuestro caso la eMMC esta soldada a la Placa. Creo que es este chip :
http://www.htcmania.com/attachment.php?attachmentid=343560&stc=1&d=1375202782

Imagen Cortesia de Rivermon.

Edito : Parece que si : http://www.samsung.com/global/business/semiconductor/product/flash-emmc/detail?productId=7706&iaId=2324

[rivermon]

Me alegro mucho que hubiese merecido la pena "destriparla" si necesitáis algún dato concreto mas se vuelve a abrir e incluso se puede despegar la especie de cinta americana y ver los integrados ocultos, tipo modulo wifi, conexiones de batería con placa que están ocultos o algún integrado que os diga algo, se hace un macro de lo que haga falta, por eso no os preocupéis

Efectivamente eso es la eMMC , buen descubrimiento

[cpro]

Me temo que en nuestro caso la eMMC esta soldada a la Placa. Creo que es este chip :

Se suponía que era Toshiba. ¿Alguien puede instalar y ejecutar algún programa de esos de comprobación de la versión del firmware de la memoria de los Samsung?

[STEVE_MARS]

He hablado con jolo por privado y me comenta que en la Dropad les ha funcionado crear una SD de arranque con el bootloader_sd.vhd.
De esta forma arranca desde la SD Externa y permite hacer una nueva instalacion.
Me ha remitido a este hilo: http://www.htcmania.com/showthread.php?t=294675
Si alguien quiere probar este metodo, que nos diga si es efectivo o no.

[cpro]

He hablado con jolo por privado y me comenta que en la Dropad les ha funcionado crear una SD de arranque con el bootloader_sd.vhd.
De esta forma arranca desde la SD Externa y permite hacer una nueva instalacion.
Me ha remitido a este hilo: http://www.htcmania.com/showthread.php?t=294675
Si alguien quiere probar este metodo, que nos diga si es efectivo o no.

En principio, formatea la SD interna para que no tenga nada: sería equivalente a hacer en el u-boot:
mmc erase boot 0 0 0
mmc erase user 0 0 0
fdisk -c 0 512 1000 500
que es lo que hacen el "utscript_1st" y el "all"

[STEVE_MARS]

Si, pero lo hace en una particion dedicada en la SD, ¿me equivoco?

[cpro]

Si, pero lo hace en una particion dedicada en la SD, ¿me equivoco?

En teoría, formatea ambas y después, en el punto 4, copia el cargador de la SD (en la externa) que, además, se carga el MBR por lo que tiene que formatearla otra vez.

Puede que si no ha podido arrancar de la SD interna lo haga desde la externa: ese cargador incluirá el código necesario para reestructurar correctamente la interna y copiar un cargador a la misma. Una vez que ha terminado el proceso, hace una actualización con un firm personalizado.

La diferencia es qué contiene la eMMC y si realmente se puede borrar o no. Por ejemplo, con las instrucciones esas de u-boot que la borrarían por completo... ¿quién nos garantiza que después arrancará desde la tarjeta SD? Salvo que ni con el utscript_1st funcionara, yo no me arriesgaría a probarlo.

[Sp4ceM4rine]

I found this:

I was able to revive the full brick!

done here as Hyundai T7 / Hyundai T7s - Talk (Post # 23798664)

4 gigs took the card, extract it from firmware bootloader_sd.vhd using WinImage 8.50.zip.
formatnul her partition using Acronis Disk Director 11 Home in fat32 and copied the firmware Inspiration_0.4

started to believe and through - the ox. black screen blinked a couple of times. after 5 - 10 minutes just pressed to believe and earned a tablet.

everything works ... : D
from:http://4pda.ru/forum/index.php?showtopic=465955&st=1140 post#1148
I think it is worth a try. It's from another russian though :risitas:

[jolocotroco]

@Sp4ceM4rine (http://www.htcmania.com/member.php?u=1093706)
Eso es lo mismo que le comente a Steve por privado, funciona en dropad y en T7, tiene que funcionar en vuestras Voyo.

[teredur]

Creo que te falta, o bien añadir la primera linea : Código: fatload mmc 1 0x41000000 set_bootargs O bien quitar estas dos : Código: source 0x41000000 utupdateenv

De acuerdo contigo, añadiria el fatload para cargar las variables de ambiente.

Estos formats : Código: ext4format mmc 0:3 ext4format mmc 0:4 Que dos particiones formatea? System y UserData?

No lo tengo nada claro por que segun parece se formatean 3 particiones:
fdisk <-c> <device_num> [<sys. part size(MB)> <user data part size> <cache part size>]

la primera parece la de system particionada en Fat.
fatformat mmc 0:1

Pero la 3 y la 4 :oh:.

Me estoy liando un poco, aver si me aclaro.
Los script entiendo que finalizan con el comando shut y que el resto es basura de versiones anteriores.

Si es asi, de nada nos sirve, por ejemplo:
mmc rescan 1;fatload mmc 1 40000000 utscript;source 40000000;movi r k 0 40008000;movi r rootfs 0 41000000 100000;bootm 40008000 41000000

Todo los movi y el bootm, no se ejecutarian.

Comentarios?

[STEVE_MARS]

Justo lo que estamos hablando, en teoria la T7s tiene la misma eMMC, es un exynos 4412.

La diferencia es qué contiene la eMMC y si realmente se puede borrar o no. Por ejemplo, con las instrucciones esas de u-boot que la borrarían por completo... ¿quién nos garantiza que después arrancará desde la tarjeta SD? Salvo que ni con el utscript_1st funcionara, yo no me arriesgaría a probarlo.
Evidentemente tiene que probarlo alguien que la tenga brickeada y que vaya a mandarla a China, no merece la pena arriesgar las nuestras que estan vivas de momento.

[STEVE_MARS]

Compañeros, tengo la sensacion que estamos muuuuy cerca...

[jolocotroco]

Hay un poco de lio, voy a liarlo un poco mas:

Si, es necesaria la linea para leer el set_bootargs en el utscript

mmc erase boot > borra el sector de arranque
mmc erase user > borra las particiones system,data y cache
fdisk -c 0 512 1000 500 > Crea las particiones, 512 system, 1000 data, 500 cache, 0 sdcard, le dara el tamaño restante.

fatformat mmc 0:1 > formatea la mmc0 particion 1 en fat
ext4format mmc 0:3 > formatea la mmc0 particion 3 en ext4
ext4format mmc 0:4> """""""""""""""""""""""""""""""" 4 """""""

estos son los puntos de montaje:

/sdcard vfat /dev/block/mmcblk0p1
/system ext4 /dev/block/mmcblk0p2
/cache ext4 /dev/block/mmcblk0p4
/data ext4 /dev/block/mmcblk0p3

[STEVE_MARS]

¿Y el recovery?
Si hace un format de las unidades cuando lo busca, en algun sitio estará ese script, ¿me equivoco?

[beachsun]

Lo del ruso es muy interesante...
No especifica como arranco la tablet, pero en el hilo original, el de Hyundai T7, hablan de arrancar con (reset)(-)(Pow), así que si lo ha hecho igual, ya tenemos la combinacion para activar el bootSD.
Esta es la linea :
9. press POWER, VOLUME DOWN and pin in reset hole. After reset keep power and volume down pressed few seconds.

[teredur]

Extraido del bootloader_sd.

Las secciones son:

bootloader
covery
kernel
ramdisk
system
cache
userdata

y viendo que la carga del Recovery segun bootloader covery es

movi r k 0 40008000
movi r covery 0 40d00000 300000
bootm 40008000 40d00000

Todo apunta a una zona de memoria por debajo de las particiones. en concreto parece que intenta leer un rootfs.

[beachsun]

Todo los movi y el bootm, no se ejecutarian. Comentarios?
Que estoy de acuerdo.... excepto si falla el comando shut ;)

Respecto a esta parte del utscript :

fastboot flash userdata 48000000
uttext 20 200 "OK, Update End !"

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

utsetbacklight 0
shut 1
reset
Es decir Flashea userdata, pinta "OK, Update End !", espera 500 segundos -> 8 Minutos.

Escribe "Reboot..." y espera otros 2000 segundos -> 33 Minutos y apaga el LCD y hae un sht y un reset...

En que momento habeis vuelto a iniciar al hacer el upgrade?
Supongo que la mayoria a vuelto a encensder despues del Update End, no?
No creo que nadie espere al reset del dispositivo...

[Manzano90]

Yo no os puedo aportar nada por que todo lo que hablais me suena a chino..xD xD !! Pero yo me ofrezco a probar todo lo que querais con la tablet, yo la tengo brickeada hace un tiempo y no la he mandado todavia por que confio en vosotros y en que deis con la solución, asique cualquier cosa que querais probar, me decis lo que tengo ke hacer y yo hare de vuestro conejillo de indias jajaja, un saludo a todos y gracias por todo

[beachsun]

Extraido del bootloader_sd.

Las secciones son:

bootloader
covery
kernel
ramdisk
system
cache
userdata

y viendo que la carga del Recovery segun bootloader covery es

movi r k 0 40008000
movi r covery 0 40d00000 300000
bootm 40008000 40d00000

Todo apunta a una zona de memoria por debajo de las particiones. en concreto parece que intenta leer un rootfs.

Uff aqui no te he podido seguir compañero...

Para mi esto :
movi r k 0 40008000
movi r covery 0 40d00000 300000
bootm 40008000 40d00000
Lo que hace es :
- carga el kernel del dispo 0 en la posicion de memoria 40008000
- carga 300000 bloques(de 512Bytes) del recovery, es decir un rootfs guardado en la seccion covery del dispo 0 en la posicion de memoria 40d00000.
- Finalmente ejecuta el kernel de la posicion 40008000 con el root de la pos 40d00000, es decir lo que acaba de cargar.

No se que quieres decir con la ultima frase...

[STEVE_MARS]

Yo no os puedo aportar nada por que todo lo que hablais me suena a chino..xD xD !! Pero yo me ofrezco a probar todo lo que querais con la tablet, yo la tengo brickeada hace un tiempo y no la he mandado todavia por que confio en vosotros y en que deis con la solución, asique cualquier cosa que querais probar, me decis lo que tengo ke hacer y yo hare de vuestro conejillo de indias jajaja, un saludo a todos y gracias por todo

Pasate por aqui que tienes trabajo :risitas::risitas::risitas:
http://www.htcmania.com/showthread.php?t=658829

Prueba lo segundo, lo del ruso, y nos cuentas que tal.

[STEVE_MARS]

Uff aqui no te he podido seguir compañero...

Para mi esto :
movi r k 0 40008000
movi r covery 0 40d00000 300000
bootm 40008000 40d00000Lo que hace es :
- carga el kernel del dispo 0 en la posicion de memoria 40008000
- carga 300000 bloques(de 512Bytes) del recovery, es decir un rootfs guardado en la seccion covery del dispo 0 en la posicion de memoria 40d00000.
- Finalmente ejecuta el kernel de la posicion 40008000 con el root de la pos 40d00000, es decir lo que acaba de cargar.

No se que quieres decir con la ultima frase...

Estamos buscando donde intenta cargar el recovery para compilar un recovery simple :ok:

[STEVE_MARS]

Que estoy de acuerdo.... excepto si falla el comando shut ;)

Respecto a esta parte del utscript :

fastboot flash userdata 48000000
uttext 20 200 "OK, Update End !"

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

utsetbacklight 0
shut 1
reset
Es decir Flashea userdata, pinta "OK, Update End !", espera 500 segundos -> 8 Minutos.

Escribe "Reboot..." y espera otros 2000 segundos -> 33 Minutos y apaga el LCD y hae un sht y un reset...

En que momento habeis vuelto a iniciar al hacer el upgrade?
Supongo que la mayoria a vuelto a encensder despues del Update End, no?
No creo que nadie espere al reset del dispositivo...

¿Segundos o milesimas?

[beachsun]

Yo no os puedo aportar nada por que todo lo que hablais me suena a chino..xD xD !! Pero yo me ofrezco a probar todo lo que querais con la tablet, yo la tengo brickeada hace un tiempo y no la he mandado todavia por que confio en vosotros y en que deis con la solución, asique cualquier cosa que querais probar, me decis lo que tengo ke hacer y yo hare de vuestro conejillo de indias jajaja, un saludo a todos y gracias por todo

Traducción libre del proceso del ruso para la Hyundai T7, que es el que el Ruso de la Voyo ha dicho que le ha funcionado... :

1. Descargar WinImage e instalar en Windows
2. Descargar la Rom de Steves y desenpaquetar.
3. Inserta la mSD en el lector de tu PC.
4. Ejecutar WinImage y selecciona Menu "DISK"(Disco) y selecciona "Restore virtual hard disk image on physical drive ..."


Elige la SD



Elige select el fichero bootloader_sd.vhd de la ROM de Steve.
Marca si para que sobreescriba la informacion

5. Si es necesario , porque no se pueda leer en Windows, formatea la particion de la mSD (2,8 GB)
6. Copia los fichero de la rom de Steve a la mSD.
7. Conecta la Tablet a la corriente.
8. Inserta la mSD en la tablet
9. Presiona POWER, VOLUME DOWN y el reset (con una aguja). Despues del reset manten pulsados Power y Volumen Down unos segundos.
10. La tablet se reflasheara...

Los comentarios del Ruso de la Voyo son :
black screen blinked a couple of times. after 5 - 10 minutes just pressed to believe and earned a tablet. everything works ...

[beachsun]

¿Segundos o milesimas?
sleep delay execution for some time N
- delay execution for N seconds (N is _decimal_ !!!)

[STEVE_MARS]

Que estoy de acuerdo.... excepto si falla el comando shut ;)

Respecto a esta parte del utscript :

fastboot flash userdata 48000000
uttext 20 200 "OK, Update End !"

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

utsetbacklight 0
shut 1
reset
Es decir Flashea userdata, pinta "OK, Update End !", espera 500 segundos -> 8 Minutos.

Escribe "Reboot..." y espera otros 2000 segundos -> 33 Minutos y apaga el LCD y hae un sht y un reset...

En que momento habeis vuelto a iniciar al hacer el upgrade?
Supongo que la mayoria a vuelto a encensder despues del Update End, no?
No creo que nadie espere al reset del dispositivo...

Personalmente en mis mas de 30 flasheos, en cuanto se apaga lo enciendo con power.
Aclarar que en terminal adb reboot no funciona, despues de iniciar correctamente dice "device not found"·.
Me extrañaria que llegara a reiniciar el tablet, ni esperando 33 minutos ni 33 horas, jejeje

[beachsun]

Que mensajes ves antes de Encenderla?

[STEVE_MARS]

Nada, en cuanto termina de flashear el system.img se apaga directamente.
Cuando enciendes lo normal, el logo de Voyo y despues arranca el bootanimation de Android.

[beachsun]

Es que eso no me encaja con el utscript :
uttext 20 180 "Update system...Wait some minutes."
movi init 0
sleep 50
fatformat mmc 0:1

ext4format mmc 0:3
ext4format mmc 0:4
sleep 50
fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000

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

sleep 1000
Segun el script :
- escribe "Update system...Wait some minutes."
- espera 50 seg
- Formatea las particiones
- espera 50 seg
- Flashea System.img
- espera 50 seg
- escribe "Update userdata...Wait some minutes."
- Flashea userdata.img
- Escribe "OK, Update End !"
- Espera 500 segundos
- Escribe "Reboot..."
- Espera 2000 segundos
- Apaga LCD
...

Te suena algo de todo eso?
En que punto reinicias?

Nadie tiene un video!!!??? ;)

[teredur]

Tengo uno, intentare subirlo, pero no es muy bueno.

No se si merece la pena:(

[teredur]

Uff aqui no te he podido seguir compañero...

Para mi esto :
movi r k 0 40008000
movi r covery 0 40d00000 300000
bootm 40008000 40d00000
Lo que hace es :
- carga el kernel del dispo 0 en la posicion de memoria 40008000
- carga 300000 bloques(de 512Bytes) del recovery, es decir un rootfs guardado en la seccion covery del dispo 0 en la posicion de memoria 40d00000.
- Finalmente ejecuta el kernel de la posicion 40008000 con el root de la pos 40d00000, es decir lo que acaba de cargar.

No se que quieres decir con la ultima frase...

Parece una zona de determinada en la emmc, como el flw1 o el u-boot.
Se podria cargar en pseudocódigo algo así como:
Fatload 1 0x40000000 recover.img
Moví w covery 0x40000000
Comentarios?

[beachsun]

Lo siento no soy capaz de seguirte... :(

El pseudo que pones esta en utscript, pero cargando un fichero que no existe en la actualizacion :
uttext 20 150 "Update recovery"
fatload mmc 1 0x40008000 ramdisk-recovery-uboot.img
movi w c 0 0x40008000 300000
uttext 20 160 "Done."
El problema es que al no existir el fichero lo mas probable es que grabe garbage de cargas anteriores, el kernel, el logo, etc...

[STEVE_MARS]

Es que eso no me encaja con el utscript :
uttext 20 180 "Update system...Wait some minutes."
movi init 0
sleep 50
fatformat mmc 0:1

ext4format mmc 0:3
ext4format mmc 0:4
sleep 50
fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000

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

sleep 1000
Segun el script :
- escribe "Update system...Wait some minutes."
- espera 50 seg
- Formatea las particiones
- espera 50 seg
- Flashea System.img
- espera 50 seg
- escribe "Update userdata...Wait some minutes."
- Flashea userdata.img
- Escribe "OK, Update End !"
- Espera 500 segundos
- Escribe "Reboot..."
- Espera 2000 segundos
- Apaga LCD
...

Te suena algo de todo eso?
En que punto reinicias?

Nadie tiene un video!!!??? ;)

Por eso digo que o no es ese utscript o son milisegundos. En tiempo real, el paso de un punto a otro es inmediato, no me extrañaría que fuera medio segundo.
Y nunca llega a reiniciar, inmediatamente que termina se apaga.

[STEVE_MARS]

Lo siento no soy capaz de seguirte... :(

El pseudo que pones esta en utscript, pero cargando un fichero que no existe en la actualizacion :
uttext 20 150 "Update recovery"
fatload mmc 1 0x40008000 ramdisk-recovery-uboot.img
movi w c 0 0x40008000 300000
uttext 20 160 "Done."
El problema es que al no existir el fichero lo mas probable es que grabe garbage de cargas anteriores, el kernel, el logo, etc...

Si, pero abriendo el bootloader en hex pone bien claro que al no encontrar el recovery formatea las particiones.
Y ahí es donde quiero llegar, ¿donde esta y que hay donde debería estar el recovery?

[Manzano90]

Pasate por aqui que tienes trabajo :risitas::risitas::risitas:
http://www.htcmania.com/showthread.php?t=658829

Prueba lo segundo, lo del ruso, y nos cuentas que tal.

Steve,la mia no enciende ni hace nada, solo se enciende la luz al cargar! Y he estado mirando lo que me has dicho, pero no entiendo bien que tengo que hacer..

[STEVE_MARS]

Sigue esta pequeña guía:
htttp://www.htcmania.com/showpost.php?p=9737390&postcount=179 (http://www.htcmania.com/showpost.php?p=9737390&postcount=179)

[beachsun]

Tengo uno, intentare subirlo, pero no es muy bueno.

No se si merece la pena:(

Pero si esta genial!!!
Si hasta puedo ver (o son imaginaciones mias) el :

OK, Update End !

Reboot...

Pero como dice Steve, o el tiempo de los Sleep son milisegundos o entre esas dos lineas habeis tenido que esperar 500 segundos -> 8 Minutazos!!! Aunque con la tension del flasheo, hay veces que 10 segundos se hacen eternos ;)

Gracias a la imagen, si tuviera que decidir, de todos los UTscript que tenemos cual ejecuta, diria que el UTSCRIPT, por la longitud de la segunda linea.

[beachsun]

Si, pero abriendo el bootloader en hex pone bien claro que al no encontrar el recovery formatea las particiones.
No lo he logrado ver, me puedes pasar el offset? entiendo que estamos hablando del fichero bootloader_sd.vhd, verdad?

Y ahí es donde quiero llegar, ¿donde esta y que hay donde debería estar el recovery?

Donde esta? Supongo que en la flash.
Que hay? Como he comentado antes, creo que hay garbage.
No comentaste que podias te entraba en recovery pero no hacia nada? Como entrabas?
Quizas si creamos un rootfs minimo y le damos el nombre ramdisk-recovery-uboot.img lo flashea y tenemos un recovery.
Y si copiamos el mismo ramdisk-uboot.img como ramdisk-recovery-uboot.img?

Comandos para escribir la eMMC :
- mmc write 0 0x40008200 0x0 0x800
- movi w k 0 0x40008000
- fastboot flash system 48000000

Alguien sabe el motivo? las diferencias?
Para empezar parece que mmc write trabaja unicamente con offsets explicitos y los otros dos tienen nombres/etiquetas/secciones que apuntan a distintos puntos de la eMMC.
Por ejemplo :
movi w k 0 0x40008000 -> W : Write - K : Kernel - 0 : dispositivo 0(eMMC) - 0x40008000 : direccion ram desde donde leer.
fastboot flash system 48000000 -> system : Parece referenciar a la particion system.

Nos falta averiguar donde apuntan esas "etiquetas".
Que haya visto :
- Flashboot Flash : tiene System y userdata
- movi : tiene k (kernel?), r (rootfs?), l (logo?), c (recovery?), rootfs(Igual que r?).
Que sabeis de esto?

[rivermon]

Que rabia no tener conocimientos para entrar en este interesantísimo intercambio del saber, y además estos conocimientos e investigaciones sin presupuesto del CSIC, de forma altruista
Gracias a todos

[cpro]

Si es que... no se os puede dejar solos, que se va uno a comer con los amigos, botella de vino, cubata... y cuando vuelve a casa tiene un montón de posts para leer :grin:

[STEVE_MARS]

Otro avance, ya tenemos gracias a jolo el bootloader_mmc.bin.
Lo hemos obtenido con:
dd if=/dev/block/mmcblk0boot0 of=/sdcard/boot0.img bs=4096
Así conseguimos el boot0.img, y lo renombramos a bootloader_mmc.bin

Se me olvidaba, para entrar en el recovery fantasma (:grin:) hay que pulsar power, vol+ y reset.
Pero repito, formatea las unidades y tendremos una tablet limpita como el culo de un bebe (lo que llamamos un full wipe de toda la vida).

[STEVE_MARS]

Si es que... no se os puede dejar solos, que se va uno a comer con los amigos, botella de vino, cubata... y cuando vuelve a casa tiene un montón de posts para leer :grin:

Pos yo me acabo de levantar de la siesta... lavin, me ha faltado solo el pijama :lengua:

[cpro]

Con lo poco que sabemos, si alguien tiene la versión original del firm, la del 6 de junio, sería posible crear un utscript que contuviera, tras la carga del entorno, algo similar a:
movi r c 0x40008000 300000
fatwrite mmc 1 0x4000800 ramdisk-recovery-uboot.img
que cogería el recovery de la memoria y lo copiaría en la SD, si las instrucciones son correctas y el firm original tenía el recovery escrito en ese punto de la eMMC.

[cpro]

Otro avance, ya tenemos gracias a jolo el bootloader_mmc.bin.
Lo hemos obtenido con:
dd if=/dev/block/mmcblk0boot0 of=/sdcard/boot0.img bs=4096
Así conseguimos el boot0.img, y lo renombramos a bootloader_mmc.bin

Se me olvidaba, para entrar en el recovery fantasma (:grin:) hay que pulsar power, vol+ y reset.
Pero repito, formatea las unidades y tendremos una tablet limpita como el culo de un bebe (lo que llamamos un full wipe de toda la vida).

No es por llevar la contraria pero eso copia sólo 4K, incluyendo el MBR. El comando, si el bl1 es como el de anrdale, que no tiene porqué ser distinto, sería:
dd if=/dev/block/mmcblk0boot0 of=/sdcard/bl1.img count=512 bs=32768 skip=1
que nos proporcionará un archivo de 16K sin el MBR, lo que es el bl1 de la arndale.

[STEVE_MARS]

No sirve, hay que buscar las particiones que nos faltan para encontrar el ramdisk-recovery kernel.
Con ls /dev/block vemos todas las particiones creadas, que son:
Dm-0, 1 y 2
Loop0 hasta 7
Mmcblk0
Mmcblk0bbot 0 y 1
Mmcblk0p1 hasta 4
Mmcblk1 y p1
Platform
Ram0 hasta 15
vold

[STEVE_MARS]

No es por llevar la contraria pero eso copia sólo 4K, incluyendo el MBR. El comando, si el bl1 es como el de anrdale, que no tiene porqué ser distinto, sería:
dd if=/dev/block/mmcblk0boot0 of=/sdcard/bl1.img count=512 bs=32768 skip=1que nos proporcionará un archivo de 16K sin el MBR, lo que es el bl1 de la arndale.

Pues no se decirte cual de las dos ordenes es correcta, o las dos, pero haciendo la que yo he puesto ya tenemos el fichero de 2 mb. y es el correcto, segun jolo :ok:

[jolocotroco]

@steve
Para poder usar el bootloader_mmc.bin hay que cambiar esto en el utscript:

fatload mmc 1 0x40008000 bootloader_sd.vhd
emmc open 0;mmc write 0 0x40008200 0x0 0x800;emmc close 0

por esto otro

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

Quedando igualito al de T7.
Si vemos con editor hex los dos archivos el vhd y el bin son identicos, lo que cambia son los primeros 200 bytes, por eso el cambio de 0x40008200 a 0x40008000.

Ahora lo que veo prioritario es buscar las particiones que faltan y poder hacer un backup de kernel, covery, ramdisk, logo, misc.

[STEVE_MARS]

Perfecto, hago el cambio y dejo un utscript totalmente usable y seguro 100% libre de bricks.
Ahora despues lo posteo para que me deis el OK.
Gracias, compi.

[cpro]

@steve
Para poder usar el bootloader_mmc.bin hay que cambiar esto en el utscript:

fatload mmc 1 0x40008000 bootloader_sd.vhd
emmc open 0;mmc write 0 0x40008200 0x0 0x800;emmc close 0

por esto otro

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

Quedando igualito al de T7.
Si vemos con editor hex los dos archivos el vhd y el bin son identicos, lo que cambia son los primeros 200 bytes, por eso el cambio de 0x40008200 a 0x40008000.

Ahora lo que veo prioritario es buscar las particiones que faltan y poder hacer un backup de kernel, covery, ramdisk, logo, misc.

Perdona que te contradiga pero no son 200B son 0x200=512, que se corresponden con el MBR. Pensaba que eso lo teníamos ya claro, que copia el primer mega, que es lo que ocupa el cargador (bootloader) menos los primeros 512B del MBR, que corresponden a una SD de 4GB, mientras que la eMMC tiene 16GB y por eso crea las particiones con el fdisk,.

[beachsun]

@steve
Para poder usar el bootloader_mmc.bin hay que cambiar esto en el utscript:

fatload mmc 1 0x40008000 bootloader_sd.vhd
emmc open 0;mmc write 0 0x40008200 0x0 0x800;emmc close 0

por esto otro

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

Quedando igualito al de T7.
Si vemos con editor hex los dos archivos el vhd y el bin son identicos, lo que cambia son los primeros 200 bytes, por eso el cambio de 0x40008200 a 0x40008000.

Ahora lo que veo prioritario es buscar las particiones que faltan y poder hacer un backup de kernel, covery, ramdisk, logo, misc.

Me interesa el fichero resultaado del dd del boot.
Si lo podeis colgar os lo agradeceria.

Entonces el fichero resultado es un fichero de 2 megas, que es igual al bootloader_sd.vhd a partir del offset 0x200?
Y como completa el mega de mas? con 0s?


Edito: no entiendo el motivo de cambiar el fichero y el script para flashear lo mismo. Algo que se me escape?
Si al fin y al cabo no se flashea el MBR...

[cpro]

Es verdad, me he equivocado: 4096 * 512B son 2MB. para obtener el archivo "bootloader_sd.vhd" habría que escribir
dd if=/dev/block/mmcblk0boot0 of=/sdcard/bootloader_mmc.bin count=2048
que es un fichero de 1MB, con el MBR incrustado, que, ahora sí, al copiarlo de memoria de 16GB a memoria de 16GB es igual.
Edito: es justo la operación inversa a lo que hace el "utscript" que, a diferencia de éste, no copia el MBR.

[beachsun]

A mi me ha parecido entender que el fichero resultante del dd no contenia el mbr.
De hecho espero que no lo contenga, porque si lo contiene el cambio en emmc open 0;mmc write 0 0x40008000 0x0 0x800;emmc close 0 es incorrecto.

[STEVE_MARS]

He creado una carpeta en Google Docs para ir poniendo ahi los utscript y tenerlos claros.
https://drive.google.com/folderview?id=0B_pz-VTEZ1hiMjhYQ05sb1Z1QnM&usp=sharing
No podemos equivocarnos con el utscript o la hemos cagao :risitas:

De momento he creado solo el que instala el system.img (100% libre de bricks) y el que es igual al de la Hyunday T7s, pero con la modificacion del bootloader de jolo.
Habria que crear otro que instalara system.img y kernel, tambien 100% libre de bricks.

[cpro]

A mi me ha parecido entender que el fichero resultante del dd no contenia el mbr.
De hecho espero que no lo contenga, porque si lo contiene el cambio en emmc open 0;mmc write 0 0x40008000 0x0 0x800;emmc close 0 es incorrecto.

Lo más seguro es que no tenga relevancia porque 0x800=2MB y estamos copiando un fichero que sólo tiene 1MB. Quiero decir que (parece que) hay reservados 2MB para el cargador principal pero, en este momento, sólo se utiliza 1MB, como mucho.

[STEVE_MARS]

Aqui teneis el boot0.img recien dd
http://www.mediafire.com/download/wud41vxm56a36pf/boot0.img

[beachsun]

He creado una carpeta en Google Docs para ir poniendo ahi los utscript y tenerlos claros.
https://drive.google.com/folderview?id=0B_pz-VTEZ1hiMjhYQ05sb1Z1QnM&usp=sharing
No podemos equivocarnos con el utscript o la hemos cagao :risitas:

De momento he creado solo el que instala el system.img (100% libre de bricks) y el que es igual al de la Hyunday T7s, pero con la modificacion del bootloader de jolo.
Habria que crear otro que instalara system.img y kernel, tambien 100% libre de bricks.

Solo un comentario : Yo todavia no llamaria nada 100% libre de Bricks.
Por otro lado, sobre el utscript del system ya se ha comentado que falta una 1a linea.

[cpro]

He creado una carpeta en Google Docs para ir poniendo ahi los utscript y tenerlos claros.
https://drive.google.com/folderview?id=0B_pz-VTEZ1hiMjhYQ05sb1Z1QnM&usp=sharing
No podemos equivocarnos con el utscript o la hemos cagao :risitas:

De momento he creado solo el que instala el system.img (100% libre de bricks) y el que es igual al de la Hyunday T7s, pero con la modificacion del bootloader de jolo.
Habria que crear otro que instalara system.img y kernel, tambien 100% libre de bricks.

No quiero quitarnos la ilusión pero, lo malo de esto, es que yo ya no me fío de nada porque la actualización del 18 de junio era, más o menos, como tu propones y no fue "libre de bricks": http://www.htcmania.com/showpost.php?p=9720290&postcount=151

[beachsun]

Aqui teneis el boot0.img recien dd
http://www.mediafire.com/download/wud41vxm56a36pf/boot0.img
Buenos, pues no tiene mbr.

Pero el resto del fichero a mi no me coincide con ningunos de los 3 ficheros bootloader_sd.vhd que tengo de 3 firmwares de la Voyo.

Con que fichero lo habeis comparado?

[STEVE_MARS]

Si no me equivoco con el bootloader_sd.vhd

[STEVE_MARS]

Salgo un rato con la bici y los niños, ahora seguimos ;-)

[cpro]

Buenos, pues no tiene mbr.

Pero el resto del fichero a mi no me coincide con ningunos de los 3 ficheros bootloader_sd.vhd que tengo de 3 firmwares de la Voyo.

Con que fichero lo habeis comparado?

No puede coincidirte porque este tiene 2MB y los otros sólo 1MB.
Edito: y si coincide con algo, tiene que ser 1MB-512B a partir del offset 512B, con el de la inspiration 0.4, que presumo que es la que STEVE tiene instalada.

[beachsun]

Ok, sorrry... se me ha ido la olla...
efectivamente es el fichero bootloader_sd.vhd del ultimo firmware sin MBR.

Pero tiene algo de mas, desde el offset 0xFFE00 hasta 0x0FFFFF, no pertenece al bootloader_sd.vhd
A partir de 0x100000 es todo 0s.

[beachsun]

Edito: no entiendo el motivo de cambiar el fichero y el script para flashear lo mismo. Algo que se me escape? Si al fin y al cabo no se flashea el MBR...

Sigo sin entenderlo, dejar el fichero original con el script original o flashear este con el script modificado, es lo mismo!!
Bueno la única diferencia es el bloque desde 0xFFE00 hasta 0x0FFFFF que en el original no existe, y mi teoria es que es garbage, ya que el script original flasheaba mas bytes de los cargados, por tanto flasheaba lo que habia en la ram...

Alguna explicacion??

[cpro]

Ok, sorrry... se me ha ido la olla...
efectivamente es el fichero bootloader_sd.vhd del ultimo firmware sin MBR.

Pero tiene algo de mas, desde el offset 0xFFE00 hasta 0x0FFFFF, no pertenece al bootloader_sd.vhd
A partir de 0x100000 es todo 0s.

Lógico (que tenga ceros), ahí no se ha copiado nada al actualizarla desde un fichero "utscript".

[beachsun]

Pero hubiera estado bien tener acceso a parte del boot que no se graba desde la SD... ;)

[cpro]

Pero hubiera estado bien tener acceso a parte del boot que no se graba desde la SD... ;)

Lo único que no se ha actualizado es el "ramdisk-recovery-uboot.img": http://www.htcmania.com/showpost.php?p=9741320&postcount=198

[beachsun]

Correcto con ese script se podria recuperar, pero creo que si hay algun recovery, estara en las tablets originales, ya que en las que se han flasheado, esa particion se ha grabado con garbage.

[teredur]

Nos falta averiguar donde apuntan esas "etiquetas".
Que haya visto :
- Flashboot Flash : tiene System y userdata
- movi : tiene k (kernel?), r (rootfs?), l (logo?), c (recovery?), rootfs(Igual que r?).
Que sabeis de esto?


extraido del boot pero tambien esta en bootloader_sd.vhd:
movi
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"

Tambien hay esto por lo que a continuacion de lo que comentaba parece que la zona de RE covery esta dentro de los 2 Mb del boot.

mmcinfo %d
reading
writing
%s FWBL1 ..device %d Start %ld, Count %ld
mmc %s %d 0x%lx 0x%lx 0x%lx
%s BL2 ..device %d Start %ld, Count %ld
%s bootloader..device %d Start %ld, Count %ld
%s kernel..device %d Start %ld, Count %ld
%s RFS..device %d Count %ld, Start %ld
%s %d TrustZone S/W.. Start %ld, Count %ld
%s Re covery..device %d Count %ld, Start %ld
%s Logo..device %d Count %ld, Start %ld, pic_index=%d

ya que para el comando fdisk nos indica que el numero de particiones es max 4

usage : fatformat <interface> <dev[:part]>
** Invalid boot device **
** Invald boot device, use 'dev[:part]' **
** Partition Number should be 1 ~ 4 **

No se si ayuda o lia mas las cosas:oh:

[cpro]

Novedad
El método de recuperación copiando el boot a la tarjeta funciona: el sistema arranca desde la mSD. :ok:

[STEVE_MARS]

Si señor, al final hemos dado con la tecla.
Y no solo para la Voyo, sino que sirve para todas las placas de Urbetter, con su boot correspondiente.
Ahora a conseguir un utscript seguro y nos vamos a por el recovery :ok:.
josemacl ha sacado una version de "actualizacion" que no formatea data ni system, para no perder los datos ni los programas instalados.
Lo curioso es que solo ha dejado el utscript_all, quitando todos los demas. Y funciona:


source 0x41000000
utupdateenv
utsetbacklight 1
uttext 20 30 "***********************************************"
uttext 20 40 "* Update System script *"
uttext 20 50 "* Script v0.1 by spektro AKA josemacl *"
uttext 20 60 "***********************************************"

uttext 20 70 "Loading environment..."
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 80 "Done"

uttext 20 100 "Update kernel..."
fatload mmc 1 0x40008000 zImage
movi w k 0 0x40008000
uttext 20 110 "Done"

uttext 20 120 "Update ramdisk..."
fatload mmc 1 0x40008000 ramdisk-uboot.img
movi w r 0 0x40008000 200000
uttext 20 130 "Done"

uttext 20 140 "Update system, wait some minutes..."
fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000
uttext 20 150 "Done"

sleep 500
uttext 20 170 "Please, reboot your device..."
sleep 4000

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 140 "Failed. Please check the recovery zImage.debug."
sleep 10
reset

sleep 500
uttext 20 160 "Please, reboot your device..."
sleep 4000

utsetbacklight 0
shut 1
reset

[cpro]

josemacl ha sacado una version de "actualizacion" que no formatea data ni system, para no perder los datos ni los programas instalados.


¿Has olvidado tú la primera línea, la que carga set_bootargs o no la ha puesto?
¿Habéis hecho la prueba de eliminar todo a excepción de zImage y system.img?

Como ya apunté, la diferencia de la actualizaión del 16 al 25 de junio es que, en la primera, no copiaban el cargador, etc.

[STEVE_MARS]

No la he puesto porque la lleva en el codigo compilado con mkimage, te adjunto el utscript_all.
http://www.mediafire.com/download/6jfwt7aj0td6jdb/utscript_all

[cpro]

Entiendo que esa es la primera línea pero no va precedida de un salto de línea que la separe de la cabecera; creo que no la añade mkimage.

Recapitulando un poco,
1.- Cuando se enciende, la pantalla no se ilumina hasta que se ejecuta un comando u-boot "utsetbacklight 1" (o equivalente, si no lo hace con u-boot) con lo que, por lo que parece, las brickeadas, en realidad, se encienden pero no lo podemos ver porque no encuentran el cargador de arranque que ejecute esa instrucción.
2.- Sí arranca de la mSD: si encuentra el cargador de arranque en la trajeta SD sigue el proceso normal, ejecutándolo desde dicho cargador. ¿Es necesario usar el RESET para que arranque desde la tarjeta o lo haría siempre que encontrara cargador en la misma?

[teredur]

Y dandole vueltas. No seria mas seguro crear 2 utscript:
- Solo flashear system.img, Para actualizaciones de la ROM, sim cambios en el kernel (zimagen), ni en el boot ( misc, boot_args,bootloader_sd-vhd).
fatload mmc 1 0x41000000 set_bootargs
source 0x41000000
utupdateenv
utsetbacklight 1
uttext 20 30 "***********************************************"
uttext 20 40 "* Update System script *"
uttext 20 50 "***********************************************"
uttext 20 70 "Update system, wait some minutes..."
fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000
uttext 20 100 "Done"
sleep 500
uttext 20 120 "Please, reboot your device..."
sleep 4000
utsetbacklight 0
shut 1
reset
sleep 1000-Flashear todo, el utscript anterior.

Otra cosa esto:

movi r c 0x40008000 300000
fatwrite mmc 1 0x4000800 ramdisk-recovery-uboot.img

No funciona, creo que no hay fatwrite.

Por lo que dura el utscript que he creado para probarlo el sleep son milisegundos.

[teredur]

2.- Sí arranca de la mSD: si encuentra el cargador de arranque en la trajeta SD sigue el proceso normal, ejecutándolo desde dicho cargador. ¿Es necesario usar el RESET para que arranque desde la tarjeta o lo haría siempre que encontrara cargador en la misma?

Ayer a la noche, [off-topic]que es unico rato que me dejan tranquilo para cacharear,[off-topic] probe varios utscript, intentando obtener informacion mediante mmcinfo y otros comandos del u-boot.
Con una tarjeta formateada con fat32 y con otra donde habia realizado el proceso de creacion del mksdboot de linaro.

He abservado que si tienes la tarjeta insertada en el proceso de inicio, vemos el logo de voyo y a los 3-4 segundos hay un cambio a negro y vuelve otra vez el logo de voyo y continua el proceso de arranque.

Si no tengo sd puesta no veo el fundido a negro.

ALguien mas puede probar?

Si es asi esta claro que intenta leer la sd en cada arranque.

[cpro]

Si es asi esta claro que intenta leer la sd en cada arranque.

No me queda claro. Cuando se actualiza no se muestra el logo de Voyo en ningún momento. Por lo que cuentas, parece que esté cargando desde la eMMC (muestra el logo) y que al detectar la tarjeta ¿intente pasar el control a la misma? y si no encuentra lo que quiera que busque, ¿recupera el control y ejecuta un código alternativo que vuelve a mostrar el logo?

Deduzco que en la tarjeta no tienes los ficheros del firm pero podrías probar una cosa: haz un utscript que recree el inicio de la eMMC en la mSD -hay algún post en que está la estructura de particiones de la eMMC, que creo que deja unos 30MB al principio- pero cambia el fichero "logo.bmp". A ver qué logo se muestra.

[beachsun]

Otra cosa esto: movi r c 0x40008000 300000 fatwrite mmc 1 0x4000800 ramdisk-recovery-uboot.img No funciona, creo que no hay fatwrite.

A mi tambien me parece que el uboot esta compilado sin el fatwrite.
Otra opcion es guardar en la mSD en Raw y recuperarlo en Raw.
Esto la deberia guardar a partir del Giga de la mSD.

utsetbacklight 1
uttext 20 30 "***********************************************"
uttext 20 40 "* Vamos a Copiar que hay en eRecovery ...Creo... *"
uttext 20 50 "***********************************************"
uttext 20 60 " "
uttext 20 70 "* Vamos a Leer el Recovery *"
movi r c 0x40008000 300000
uttext 20 80 "* Recovery Leido, vamos a escribirlo en la SD a Partir del Giga*"
mmc write 1 0x40008000 2097152 6144
uttext 20 90 "* Grabado Recovery Leido, vamos a escribirlo en la SD a Partir del Giga*"
uttext 20 100 "* Ahora me voy a quedar esperando que reinicies...*"
sleep 500000

suponiendo que : MMC Write Device OffsetRam NroBlkStart NroBlk

En resumen :
Leemos 0x300000 Bytes(3megas exactos) y los ponemos en 0x40008000
Escribimos en la mSD ( device 1) el contenido de 0x40008000, a partir del bloque 2097152(a 512B el bloque -> 1024 megas, para evitar machacar los ficheros del upgrade), y graba 6144 Bloques (3 megas).

Una vez hecho tendremos a partir del bloque 2097152 de la mSD, durante 3 megas el contenido de la particion recovery de vuestra voyo, y digo vuestra porque creo no todo el mundo tendra lo mismo...

Utilizar un mSD de 2GB por lo menos, que este limpia, unicamente formateada fat32 y los ficheros del upgrade con el utscript modificado.
Despues

[STEVE_MARS]

Y dandole vueltas. No seria mas seguro crear 2 utscript:
- Solo flashear system.img, Para actualizaciones de la ROM, sim cambios en el kernel (zimagen), ni en el boot ( misc, boot_args,bootloader_sd-vhd).
fatload mmc 1 0x41000000 set_bootargs
source 0x41000000
utupdateenv
utsetbacklight 1
uttext 20 30 "***********************************************"
uttext 20 40 "* Update System script *"
uttext 20 50 "***********************************************"
uttext 20 70 "Update system, wait some minutes..."
fatload mmc 1 0x48000000 system.img
fastboot flash system 48000000
uttext 20 100 "Done"
sleep 500
uttext 20 120 "Please, reboot your device..."
sleep 4000
utsetbacklight 0
shut 1
reset
sleep 1000-Flashear todo, el utscript anterior.

Otra cosa esto:

movi r c 0x40008000 300000
fatwrite mmc 1 0x4000800 ramdisk-recovery-uboot.img

No funciona, creo que no hay fatwrite.

Por lo que dura el utscript que he creado para probarlo el sleep son milisegundos.

Efectivamente, por eso he creado una carpeta compartida en Gdocs con los dos Utscript.
Voy a crear un hilo nuevo, con este tema de la carpeta compartida.

EDITO: ya está, http://www.htcmania.com/showthread.php?t=659646

[cpro]

Pues nada, compis, que después de que Digimagic haya recuperado su cacharro sin pulsar RESET (qué envidia, que yo la mandé a China hace un mes), creo que el primer dispositivo de arranque es la eMMc y el segundo la SD. Que si conseguimos modificar el bl2, podremos hacer lo que nos porpongamos. ¡Hala, a estudiar!! ;-)

[beachsun]

Coñe, cpro, no sera al reves? Si encuentra el "boot" en la mSD, arrfanca de mSD y si no,arranca de eMMC.

[cpro]

Coñe, cpro, no sera al reves? Si encuentra el "boot" en la mSD, arrfanca de mSD y si no,arranca de eMMC.

Esa fue mi primera idea hace tiempo pero ahora creo que no porque a STEVE no le hacía nada cuando ponía el boot de la Arndale.

Por esto mismo es por lo que pedí a teredur que, si podía, recreara el boot de la eMMC en una SD, cambiando el "logo.bmp", para ver qué imagen mostraba al arrancar.

[beachsun]

Ok, creo que ahora te he entendido.
Lo que dices es que no esta claro si ha arrancado de la mSD porque es lo primero que intenta o porque no ha podido arrancar de la eMMC.
Habrá que averiguarlo... ;)

[beachsun]

Me tiene intrigado donde carga el fichero MISC, con este utscript copiamos todo el "boot" de nuevo a la mSD(1mega a partir del 1er Giga) :

utsetbacklight 1
uttext 20 30 "********************************************* **"
uttext 20 40 "* Vamos a Copiar que hay en Boot ...Creo... *"
uttext 20 50 "********************************************* **"
uttext 20 60 " "
uttext 20 70 "* Vamos a Leer el Boot *"
emmc open 0;mmc read 0 0x40008200 0x0 0x800;emmc close 0
uttext 20 80 "* Boot Leido, vamos a escribirlo en la SD a Partir del Giga*"
mmc write 1 0x40008000 2097152 2048
uttext 20 90 "* Grabado Recovery Leido, vamos a escribirlo en la SD a Partir del Giga*"
uttext 20 100 "* Ahora me voy a quedar esperando que reinicies...*"
sleep 500000


Extraemos ese mega de la mSD en un fichero y podemos buscar dentro del fichero el contenido del fichero MISC para ver donde lo ha flasheado...

[cpro]

Me tiene intrigado donde carga el fichero MISC, con este utscript copiamos todo el "boot" de nuevo a la mSD(1mega a partir del 1er Giga) :


Me parece que tienes un fallo en el código, en la dirección, pero no es necesario: lo tenemos ya en el fichero que nos pasó STEVE creado a partir de la instrucción que pasó jolocotroco.

Extraes del mismo lo que (teoricamente) se ha copiado del misc a partir de la dirección que se supone que se copia y ya los podrás comparar ;-)

[beachsun]

En que direccion? en la direccion ram donde se almacena temporalmente? porque?
Coñe es cierto que esta en el fichero de Steve, voy a ver si encuentro la información de MISC...

Edito... Muy curioso.... No ta!!!

[cpro]

Creo que entiendo el problema de las mSD de más de 8GB: u-boot sólo debe de reconocer FAT32 y por defecto, Windows debe de formatear en FAT16 1GB y 2GB, en FAT32 4GB y 8GB y las de 16GB en adelante en NTFS; si el usuario no sabe/entiende, no se fija en qué lo ha formateado Windows.

Pero sabiendo esto, aunque sea sólo una conjetura, cualquier tarjeta (de 32GB o menos, que se supone que es el lector) debería poder usarse si está formateada en FAT32.

Si se queda tonta tras la actualización, se copia el bootloader_sd.vhd a la raíz de la tarjeta. Seguramente, con el administrador de discos podrían eliminarse las cuatro particiones y hacer sólo una para que ocupe todo lo que sea la tarjeta, formateándola en FAT32 (sólo si la tarjeta es de más de 4). Se copian ahí los archivos de actualización y se arranca. Ya sabemos que si tiene el bootloader en la tarjeta no hace falta presionar el reset ¿hará falta presionar el Vol(-)?

[cpro]

En que direccion? en la direccion ram donde se almacena temporalmente? porque?
Coñe es cierto que esta en el fichero de Steve, voy a ver si encuentro la información de MISC...

Edito... Muy curioso.... No ta!!!

Lo de la dirección es porque has puesto la instrucción inversa a la que hace su script. Era sólo porque tenías que tener en cuenta que añadías 512 (presumiblemente, ceros) al principio.

Intentaré echar un ojo mañana.

[teredur]

Por esto mismo es por lo que pedí a teredur que, si podía, recreara el boot de la eMMC en una SD, cambiando el "logo.bmp", para ver qué imagen mostraba al arrancar.

He creado la SD de recuperación con el bootloadersd.vhd, y formateado el espacio fat.

Crea un espacio de 32Mb mas 3 particiones adicionales mas la particion del espacio fat.
En el espacio inicial aparece el boot (bl1,bl2,uboot) al igual que creaba el mkbootsd de arndale, no he comprabado si son identicos.
En las particiones restantes no he encontrada ninguna estructura conocida, no logo, ni misc, ni na..

Asi que el logo que muestra lo lee de la emmc.

Sigo en busca de la zona de REcovery y hasta ahora he visto:

- En /dev/block/mmcblk0boot0, se encuentra parte del boot (bl1,bl2,uboot,tzsw)
-/dev/block/mmcblk0boot1 esta a 0
-En el espacio que deja hasta el bloque 9 de /dev/block/mmcblk0 cada bloque es de 8225280 bytes
0x84e00 - zimagen - kernel
0x684e90 - ramdisk-uboot.img
0x80e00 - misc
0x1800000 - logo
0x1c00000 - bootres

Ya hemos encontrado el misc.:ok:

[cpro]

Gracias por la información.

He creado la SD de recuperación con el bootloadersd.vhd, y formateado el espacio fat.

A lo que yo me refería era a crear un utscript que escribiera las cosas en la tarjeta SD en lugar de en la eMMC para que, en el siguiente arranque, según el logo que vieras, pudiéramos averiguar si arrancaba de una memoria o de otra y cuándo.
Para ello (en el utscript) no hace falta ni formatear ni instalar el sistema, sólo la información que hay en esos treinta y tantos megas.

[cpro]

Como indica teredur, fdisk muestra la siguiente estructura de la eMMC:
Disk /dev/block/mmcblk0: 15.6 GB, 15634268160 bytes
255 heads, 63 sectors/track, 1900 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 265 1893 13076480 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 9 74 524288 83 Linux
/dev/block/mmcblk0p3 74 201 1024000 83 Linux
/dev/block/mmcblk0p4 201 265 512000 83 Linux

Partition table entries are not in disk order
Por ello, hago un volcado de los primeros 74MB de la eMMC:
dd if=/dev/block/mmc of=emmc.img bs=8225280 count=9

Pero curiosamente, el MBR de la imagen dice que ocupa 64MB:
fdisk -l del "emmc.img"

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
emmc.img1 4251648 30404607 13076480 c W95 FAT32 (LBA)
emmc.img2 131072 1179647 524288 83 Linux
emmc.img3 1179648 3227647 1024000 83 Linux
emmc.img4 3227648 4251647 512000 83 Linux

Las entradas de la tabla de particiones no están en el orden del disco

Hago un volcado con "hexdump -C emmc.img" (anotado por mi):

1.- Esto es el MBR
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................|
000001c0 01 00 0c fe ff ff 00 e0 40 00 00 10 8f 01 00 01 |........@.......|
000001d0 01 00 83 fe ff ff 00 00 02 00 00 00 10 00 00 01 |................|
000001e0 01 00 83 fe ff ff 00 00 12 00 00 40 1f 00 00 01 |...........@....|
000001f0 01 00 83 fe ff ff 00 40 31 00 00 a0 0f 00 55 aa |[email protected].|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
* 2.- Aquí comienza "misc"
00080e00 7e 5b cb f5 62 61 75 64 72 61 74 65 3d 31 31 35 |~[..baudrate=115|
00080e10 32 30 30 00 62 6f 6f 74 63 6d 64 3d 73 65 74 64 |200.bootcmd=setd|
2.- Esto es el fichero "misc"
00081120 33 00 62 6c 74 79 70 65 3d 70 00 00 00 00 00 00 |3.bltype=p......|
00081130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
* 3.- "misc" terminado y comienza "zImage"
00084e00 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 |................|
*
00084e20 02 00 00 ea 18 28 6f 01 00 00 00 00 d0 7d 4b 00 |.....(o......}K.|
00084e30 01 70 a0 e1 02 80 a0 e1 00 20 0f e1 03 00 12 e3 |.p....... ......|
3.- Esto es contenido de "zImage"
0053cbb0 f0 7d 4b 00 e8 7d 4b 00 28 09 00 00 e0 7d 4b 00 |.}K..}K.(....}K.|
0053cbc0 d0 7d 4b 00 dc 7d 4b 00 e4 7d 4b 00 00 00 00 00 |.}K..}K..}K.....|
3.- Aquí ha terminado "zImage"
0053cbd0 ff ef ff ff ff f7 df ff ff ff ff ff ff ff ff ff |................|
0053cbe0 de ff ff ff ff ff d7 ff ff df 7f ff fe ff ff ff |................|

MAS DATOS

00684de0 ff ff ff ff 7f ff ff ff 6f ff f6 ff ff ff ff fd |........o.......|
00684df0 ff ff bf fb 77 df bf ff ff fe ff ff ff bf ff ff |....w...........|
4.- Aquí empieza "ramdisk-uboot.img"
00684e00 27 05 19 56 a0 48 ab cc 51 d1 4a 8d 00 02 df 2d |'..V.H..Q.J....-|
00684e10 40 80 00 00 40 80 00 00 42 78 0b 5a 05 02 03 00 |@[email protected]....|
00684e20 72 61 6d 64 69 73 6b 00 00 00 00 00 00 00 00 00 |ramdisk.........|
4.- Contenido de "ramdisk-uboot.img"
006b2d30 dd 68 5e d4 88 08 d5 60 8b c2 f6 d1 8e ce de e5 |.h^....`........|
006b2d40 d3 22 a0 7f 57 56 45 08 e9 bd 8e 52 53 67 a9 f7 |."..WVE....RSg..|
006b2d50 ce fe f2 f7 ca 86 07 3b ba 7b 36 0d 2e 5e bc 98 |.......;.{6..^..|
006b2d60 5e c3 eb bf 01 83 7c d4 4e 00 0d 05 00 95 23 c6 |^.....|.N.....#.|
4.- Aquí ha terminado "ramdisk-uboot.img" ("95 23 c6" no pertenecen al archivo)
006b2d70 24 db 89 c8 31 05 64 3b 74 ce c3 91 b1 79 86 78 |$...1.d;t....y.x|
006b2d80 4c d4 c6 6c 6a c3 e8 ae c1 bc 31 26 d2 95 4e c4 |L..lj.....1&..N.|

MAS DATOS

00884df0 cf 11 26 43 d7 bf f4 86 e3 dd 93 19 df 32 73 bb |..&C.........2s.|
00884e00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
* 5.- Aquí comienza "bootres"
01000000 42 4d 14 7d 01 00 00 00 00 00 36 00 00 00 28 00 |BM.}......6...(.|
01000010 00 00 04 01 00 00 7d 00 00 00 01 00 18 00 00 00 |......}.........|
01000020 00 00 de 7c 01 00 12 0b 00 00 12 0b 00 00 00 00 |...|............|
01000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01000090 00 00 00 00 04 00 00 10 10 00 18 18 00 24 20 00 |.............$ .|
010000a0 30 30 00 38 38 00 40 40 00 40 40 00 3c 38 00 34 |00.88.@@.@@.<8.4|
5.- Contenido de "bootres"
010e4ba0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
010e4bd0 12 28 24 3b 78 6d 00 00 00 00 00 00 00 00 00 00 |.($;xm..........|
010e4be0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
* 5.- Aquí acaba "bootres"
010fa000 a7 d1 fa 37 de 38 08 99 38 94 79 83 64 e7 37 0e |...7.8..8.y.d.7.|
010fa010 76 b1 ec fb 02 f1 05 92 29 8d 2d 2c 0f 7b 32 9b |v.......).-,.{2.|

MAS DATOS

01300000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
* 6.- Aquí comienza el fichero "logo.bmp"
01800000 42 4d 38 8c 0a 00 00 00 00 00 36 00 00 00 28 00 |BM8.......6...(.|
01800010 00 00 e0 01 00 00 e0 01 00 00 01 00 18 00 00 00 |................|
01800020 00 00 02 8c 0a 00 12 0b 00 00 12 0b 00 00 00 00 |................|
01800030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01801ec0 00 00 00 00 00 00 00 00 00 00 00 00 02 01 00 02 |................|
6.-Sigue siendo contenido de "logo.bmp"
018a8a40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
018a8c30 00 00 00 00 00 00 00 00 b4 d7 0a 5f 62 1b cb 97 |..........._b...|
6.-Hasta 018a8c38 es contenido de "logo.bmp" (los ceros).
018a8c40 2d 19 6b 4c fb 50 97 63 f1 a9 b1 f8 d5 1e 76 c7 |-.kL.P.c......v.|
018a8c50 73 cc 38 10 7f ae c5 dc ff ab 9e ce 1f d3 ff 0d |s.8.............|

MAS DATOS

01cffff0 b5 15 3c 3f aa e0 fe 34 f5 fc 8d 78 7e 9a 2a 73 |..<?...4...x~.*s|
01d00000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
* 7.- Los 64MB son la dirección "04000000": Comienzo de la partición mmcblk0p2, system
04000400 00 80 00 00 00 00 02 00 00 00 00 00 ee 97 00 00 |................|
04000410 6b 7a 00 00 00 00 00 00 02 00 00 00 02 00 00 00 |kz..............|

Fundamentalmente, cambia la dirección de "bootres" que había encontrado teredur pero es porque son varias imágenes BMP concatenadas, que son mostradas como una animación. NOTA: los "*" los imprime "hexdump" cuando todo el contenido son ceros.

También he extraido "ramdisk-recovery-uboot.img" con el código de utscript
movi r c 0 0x40008000 300000
mmc write 1 0x40008000 0x0 300000
El contenido del mismo empieza en la dirección de "bootres" y a continuación, contiene datos hasta la dirección 0x300000. No obstante, no tengo muy claro qué significa el "300000" de "mmc write" porque en el caso de "misc" escribe "20" para copiar 0x84e00-0x80e00=0x4000=65KB y parece raro que sea 0x81129-0x80e00=0x329 o algún valor próximo. Con una tarjeta SD de clase 4, ha tardado unos 4 minutos en ejecutar ese "utscript".

[cpro]

A lo que yo me refería era a crear un utscript que escribiera las cosas en la tarjeta SD en lugar de en la eMMC para que, en el siguiente arranque, según el logo que vieras, pudiéramos averiguar si arrancaba de una memoria o de otra y cuándo.
Para ello (en el utscript) no hace falta ni formatear ni instalar el sistema, sólo la información que hay en esos treinta y tantos megas.

Me respondo a mi mismo:
He intentado crear la tarjeta tanto con "utscript" como a través de dd y ha sido totalmente infructuoso: no arranca desde la tarjeta SD, sólo podemos gestionar las cosas con ficheros de comandos de u-boot (utscript).

[STEVE_MARS]

Un gran curro y excelente informacion, si señor.
Gracias, cpro :dios::aplausos:.

[rivermon]

Parece que va por buenos caminos
Que suerte tenemos de que estéis entre nosotros
Graciasssssssss

[teredur]

movido

[cpro]

.

Alguna idea de porque no arranca.

He extraido el ramdisk y coincide exactamente con el archivo "ramdisk-uboot.img".

Edito: He estado usando el sistema raíz de la Voyo para hacer un initrd (que la idea me la dio STEVE) y probar si arranca con bootm. Yo no sé si usar ahí mkimage ya que el ramdisk-uboot no sigue el modelo de Android. Acabo de hacer el "mkrootfs" y esta tarde haré el utscript para probar si lo reconoce y funciona.

Edito2: Me he confundido y hablas de la zona del recovery. Lo tienes al final del mensaje que puse anoche: empieza en "bootres", pero no he comprobado qué sigue hasta 0x300000. Con respecto a otro mensaje que pusiste, aunque no recuerdo en qué hilo, con "vol(+)+pow" sí aparece dos veces el logo. Puede que sea porque ejecuta el recovery.

[exxtrema]

Estoy en el dentista esperando entrar pero la euforia no me deja, la puta de la tablet que se a flaseado, me a dejado flipado !!! Salia por la puerta de casa y veo el logo de voyo!!!!!!. Ya se donde estaba el error, estaba en el lector de tarjetas ya que lo hice desde el s3 con una apli para poner el movil en ums ya que la salida del usb esta en mtp y realice el proceso con el programa wim... que me dijiste la semana pasada y todo a la primera, puto lector me hace cosas extrañas y claro es un usb que me lleve al otro pc, total que sale el inhalador de la rom con una línea de pixel a la izquierda y al rato el logo de voyo! !!!! Sois unos putos crack , habéis montado un buen equipo y ya queda confirmado que se recupere de todas todas!!!! Felicidades por tu trabajo eres un máquina

otro mas que a conseguido recuperar la tablet del brick que produce la actualización gracias al team voyo!!!!!