Reparar un Tagus brickeado: cómo romper el bucle de recovery por UART
Mi Tagus se quedó atrapado en un bucle infinito intentando instalar una actualización que no existe. Así lo recuperé sin ADB, solo con un adaptador USB-UART.
Uno de mis Tagus amaneció en coma. Arrancaba, entraba en recovery, intentaba instalar algo que no existía, fallaba, y se reiniciaba. Una y otra vez. Sin ADB, porque el recovery no expone el puerto USB. Sin poder tocar la pantalla, porque el táctil de este Tagus está roto.
Aquí está todo lo que hice para recuperarlo usando solo un adaptador UART de 3 euros y BusyBox.
Los síntomas
El dispositivo arranca, muestra el logo del bootloader, y entra directamente en recovery. En el log por UART se ve claro:
got recovery cmd from misc.
...
Boot command: boot-recovery
list arg=2:
recovery
--update_package=/data/local/assets/update.zip
...
I/: Update location: /data/local/assets/update.zip
E/: failed to open /data/local/assets/update.zip (No such file or directory)
E:signature verification failed
Installation aborted.
El recovery tiene un comando grabado en la partición misc que le dice “instala update.zip”. Como ese archivo no existe (probablemente lo borró una actualización anterior), falla la verificación de firma y aborta. Pero el comando sigue ahí, así que en el siguiente arranque vuelve a intentarlo. Bucle infinito.
Lo que necesitas
- Un adaptador USB-UART TTL 3.3V (cualquier CP2102, FT232 o PL2303 barato sirve)
- Cables para conectar GND, TX y RX a la placa base
- Un ordenador con terminal serie (en Mac,
screenviene incluido) - Saber soldar o tener un conector JST para los pines UART de la placa
No conectes VCC. Solo GND, TX y RX.
Paso 1: Conectar por UART y ver el log
Localiza los pines UART en la placa base. En el Tagus Gea/Gaia están etiquetados y son accesibles sin desmontar casi nada.
Conecta:
- GND del adaptador a GND del Tagus
- TX del adaptador a RX del Tagus
- RX del adaptador a TX del Tagus
En el Mac, identifica el puerto:
ls /dev/tty.*
Conéctate a 115200 baudios (la velocidad estándar de U-Boot y kernels Linux embebidos):
screen /dev/tty.usbserial-XXXXX 115200
Enciende el Tagus y verás el log de arranque completo. El sistema acaba en un shell # de recovery cuando termina de fallar.
Paso 2: Explorar con BusyBox
Los comandos normales de Linux no están en el recovery de este dispositivo. Pero sí está BusyBox, que agrupa docenas de utilidades:
busybox
Esto lista todos los comandos disponibles. Todos se usan anteponiendo busybox:
busybox ls
busybox dd
busybox hexdump
busybox mount
busybox reboot
Paso 3: Encontrar la partición misc
En Android/RockChip, la partición misc almacena el comando de arranque. Para saber qué dispositivo de bloque es:
busybox ls -l /dev/block/platform/1021c000.rksdmmc/by-name/misc
Resultado:
misc -> /dev/block/mmcblk0p3
Paso 4: Leer el comando maldito
Con hexdump vemos el contenido binario de la partición:
busybox hexdump -C /dev/block/mmcblk0p3 | busybox head
El comando de recovery empieza en el offset 0x4000 (16384 bytes):
00004000 62 6f 6f 74 2d 72 65 63 6f 76 65 72 79 00 00 00 |boot-recovery...|
00004040 72 65 63 6f 76 65 72 79 0a 2d 2d 75 70 64 61 74 |recovery.--updat|
00004050 65 5f 70 61 63 6b 61 67 65 3d 2f 64 61 74 61 2f |e_package=/data/|
00004060 6c 6f 63 61 6c 2f 61 73 73 65 74 73 2f 75 70 64 |local/assets/upd|
00004070 61 74 65 2e 7a 69 70 0a 00 00 00 00 00 00 00 00 |ate.zip.........|
Aprendizaje clave: el comando no está al principio de la partición. Está en el bloque 16 (offset 0x4000). Si hubiera intentado borrar desde el principio, no habría servido de nada.
Paso 5: Borrar el comando
Con dd sobrescribimos esa zona exacta con ceros:
busybox dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=1k seek=16 count=1
Parámetros:
if=/dev/zero— fuente: ceros.of=/dev/block/mmcblk0p3— destino: la partición misc.bs=1k— bloques de 1 KB.seek=16— saltar 16 bloques (16384 bytes) antes de escribir.count=1— escribir solo 1 bloque, suficiente para borrar el comando.
Paso 6: Verificar
busybox hexdump -C /dev/block/mmcblk0p3 | busybox head -20
La zona del offset 0x4000 debe estar llena de ceros.
Paso 7: Reiniciar
busybox reboot
Si el comando no responde, alternativa:
echo b > /proc/sysrq-trigger
El dispositivo ya no intenta instalar una actualización fantasma. Arranca normalmente.
Por qué funciona
La partición misc de Android usa un formato llamado bootloader message. El bootloader (U-Boot, en este caso) la lee al arrancar y, si encuentra boot-recovery, carga la partición recovery en lugar de boot. El recovery a su vez lee el resto del mensaje para saber qué hacer.
Borrando el mensaje, el bootloader no encuentra razones para entrar en recovery. Vuelve al arranque normal.
Notas y riesgos
- Haz copia de seguridad antes de tocar particiones:
busybox dd if=/dev/block/mmcblk0p3 of=/sdcard/misc-backup.img - El offset exacto puede variar según el fabricante. Siempre confirma con
hexdumpantes de escribir. - Modificar particiones del sistema conlleva riesgo de brick. Pero cuando ya estás en un bucle infinito, no hay mucho más que perder.
El log completo
Para referencia, el log de arranque completo del Tagus en este estado está disponible como referencia. Cubre U-Boot, el kernel Linux 3.10, la inicialización de Rockchip, el panel e-ink (ED060XH7), el PMIC AXP223/TPS6518x, y el recovery de Android 4.4.2 con todos los mensajes de error relevantes.
Es un documento útil si estás depurando problemas similares en cualquier dispositivo RockChip RK3128 con pantalla e-ink de Onyx.
Borrador con IA, edición a mano. Lo publico cuando me suena a mí.