Actualizado: he retocado algunos detalles de la línea de configuración que eran incorrectos. Al escribir la entrada corté y pegué una línea que no era.

Un colega me regaló una vieja tablet que no funcionaba para aprovechar piezas, pero como encendía y llegaba a hacer algo, decidí ver si podía resucitarla (sí, la pantalla está rota; afortunadamente sólo es el plástico, el LCD está en perfecto estado).

El primer intento consistió en encenderla pulsando a la vez el botón de encendido y el de subir volumen para entrar en modo de rescate, a ver si conseguía restaurar el sistema Android. Aparentemente funcionó, pero al intentar arrancar se volvía a quedar a la mitad, por lo que empecé a sospechar que el problema estaba en la memoria flash interna, pero para demostrarlo necesitaba acceder al sistema de alguna manera.

Echando un vistazo por dentro encontré que había cuatro pads en una esquina marcados como gnd, tx, rx y 3,3v, por lo que sospeché que podría tratarse de un puerto serie de depuración. Estos puertos serie son bastante habituales en aparatos de consumo, pero tienen el inconveniente de que trabajan con niveles TTL (0 voltios para un cero, o 5 o 3,3 voltios para un uno) en lugar de las tensiones estándar del RS-232 (3/15 voltios para un cero, -3/-15 voltios para un uno). Existen algunos conversores de serie TTL a USB, pero por diversos motivos preferí hacerme una placa con un MAX 3232 y un conversor RS-232 a USB normal y corriente. El MAX3232 es un chip similar al conocido MAX232, que convierte los niveles entre un puerto serie TTL y uno RS-232, pero con la ventaja de admitir tensiones de alimentación entre 3 y 5,5 voltios (el MAX232 está limitado a 5 voltios). Con este chip pude conectar la tablet a mi PC (pulsa en la imagen para ampliar).

Un detalle importante es que fue necesario soldar dos puentes para activar el puerto serie. Están marcados con un círculo rojo en la siguiente fotografía (pulsa en la imagen para ampliar):

Una vez hechos los puentes y lanzado el minicom con el puerto serie configurado a 115.200 8N1, apareció el texto de arranque. Ahí pude ver que, como esperaba, primero cargaba el U-Boot, y éste cargaba el núcleo Linux de Android, siguiendo el proceso habitual. Sin embargo, al llegar a cierto punto empezaron a salir errores de lectura de la flash, tal y como temía. Sin embargo, decidí probar si podía conseguir acceso al U-Boot para cambiar las opciones de arranque, y sí, fué posible: pulsando la tecla Return en el terminal varias veces en el momento de encender la tablet detiene el proceso de arranque y ofrece un prompt en el que se puede jugar con muchas opciones.

Con el comando print eché un vistazo a las variables de entorno, y encontré la que me interesaba: la que contiene el parámetro bootargs. Esta variable define los parámetros de arranque que se le pasan al núcleo al arrancar, tales como la partición con el sistema de ficheros raíz y otras. En el caso de esta tablet, sin embargo, el proceso es ligeramente oscuro, pues lo que se hace es llamar a un script que define en cada momento la variable bootargs en función de lo que sea necesario. En concreto, este es el script tal y como viene definido:

set-rfs-ram-ota=setenv bootargs mem=${memtotal} root=/dev/ram0 rw initrd=${load-addr-initrd},0x${filesize} console=ttyS0,115200n8 init=/init androidboot.serialno=${androidboot.serialno}

Para hacer una primera prueba introduje la tarjeta de memoria de mi otra tablet, la cual ya tiene un sistema Debian completo, junto con mi gestor de ventanas para tablets, y modifiqué la entrada anterior con:

setenv set-rfs-ram-ota setenv bootargs mem=${memtotal} root=/dev/mmcblk0p2 rw rootdelay=1 console=ttyS0,115200n8

El dispositivo /dev/mmcblk0p2 es la partición segunda de la tarjeta microSD, que es donde tengo el sistema Debian. Al principio le añadí un rootdelay=7 para retrasar siete segundos el montaje de la partición raíz, pensando que tardaría un poco en detectar la tarjeta, pero al final no es necesario. En cambio, si se quiere arrancar desde una partición en un disco USB, es muy probable que dicha opción sea necesaria para darle tiempo al núcleo a detectar los dispositivos.

Y con  esto la tablet arrancó perfectamente (pulsa en la imagen para ampliar):

Ahora voy a probar a compilar mi propio núcleo y a intentar arrancarlo desde la tarjeta microSD.

Hace tiempo me compré unos cascos inalámbricos, en concreto el modelo MDR-RF810R de Sony. Mi intención era utilizarlos con el ordenador, para olvidarme de los molestos cables.

Los cascos y el transmisor

Por desgracia, sólo puedo utilizarlos con la televisión porque tienen un serio defecto: a los cuatro minutos de no recibir señal acústica la base transmisora se apaga (supuestamente para ahorrar energía… lo que es ridículo porque no usa pilas sino un transformador; son los cascos en sí los que utilizan baterías, y ellos nunca se desconectan). En ese momento los cascos pegan un petardazo muy fuerte. Con la tele no es un problema porque cuando termino de verla, la apago y me quito los cascos, pero con el ordenador puedo ver un vídeo y, al terminar, seguir leyendo o trabajando con los cascos puestos, por lo que cuatro minutos después, estando todo en pleno silencio, los cascos me sueltan el petardazo sin previo aviso. Afortunadamente no es muy difícil resolver este problema, así que en esta entrada voy a explicar como lo hice.

Una mirada al interior

Al desmontar el transmisor nos encontramos con este circuito.

Un circuito bastante sencillo

A primera vista parece muy sencillo: un par de transistores que, probablemente, amplifiquen un poco la entrada, algunos condensadores de filtrado, y una caja metálica que, seguramente, contiene la parte de alta frecuencia. Pero en realidad tiene truco, porque si le damos la vuelta nos encontramos con el verdadero circuito:

Parece que hablamos demasiado pronto…

El primer gran problema que nos encontramos es que los números de los chips están borrados. Afortunadamente hay uno que sí se puede leer más o menos, y que resulta ser un chip con cuatro amplificadores operacionales. Analizando el circuito que lo acompaña se nota cierta estructura simétrica, lo que nos hace sospechar que puede tener que ver con algún tipo de proceso de señal estéreo.

Tras analizar con cuidado todo, llegamos a la conclusión de que la señal de sonido se divide en dos partes: por un lado se envía directamente al chip de la derecha, que resulta ser un modulador de FM, y por otro se envía a ese circuito que vimos antes, donde se detecta si hay o no señal. La salida del modulador de FM es una señal en banda base modulada en estéreo, la cual se pasa al transmisor localizado dentro de la caja metálica en el otro lado de la placa, que sube la frecuencia hasta la banda deseada y la envía a la antena. Este transmisor recibe su alimentación a través de un regulador de tensión diferente al del resto de la circuitería, el cual, además, está controlado desde el modulador de FM para poder encenderlo y apagarlo a voluntad.

Al principio se me ocurrió que si forzaba la alimentación del transmisor, de manera que siempre estuviese encendido, resolvería el problema. Por desgracia no funcionó. Sospecho que es porque se trata de un simple elevador de frecuencia, por lo que si no hay una señal desde el modulador de FM, la salida sigue siendo nula. Ante esto llevé mi investigación al resto del circuito.

Bloques principales del transmisor FM

El detector/amplificador de pulsos detecta cuando hay señal de audio en la entrada del transmisor, momento en que activa el transistor de conmutación. De esta manera éste conecta su salida a masa cuando hay una señal de audio, o la deja flotante cuando no la hay, en cuyo caso una resistencia de pull-up fija una tensión de entre 4,8 y 5,6 voltios. Esta salida está conectada directamente al modulador de FM (línea naranja), y es la que reinicia el contador de cuatro minutos de apagado cada vez que se detecta señal.

La deducción lógica de todo esto es que, para que el transmisor no se desactive nunca, basta con cortocircuitar dicho transistor, de manera que su salida esté siempre a cero voltios, haciendo creer así al modulador FM que hay una señal de audio en todo momento. Para ello basta con cortocircuitar los dos pines marcados en la imagen de abajo con la línea rosa (el círculo rodea al transistor de conmutación):

El circulo naranja rodea al transistor de conmutación; el trazo rosa indica los dos pines que hay que cortocircuitar

Y con esto resolvemos el problema y ya podemos usar los cascos sin miedo a sobresaltos.

En la entrada anterior expliqué como hice para arrancar una Debian en mi dispositivo AndroidTV. Hoy estuve retocando el código para hacerlo más flexible y corregir algunos problemas de tipo práctico que he encontrado al empezar a usarlo de manera regular.

Cambios en launch_debian

El primer cambio ha sido en el propio launch_debian. Este binario es el encargado de detectar cuando se enchufa un disco externo y de lanzar la aplicación runlinux.sh que esté en su directorio raíz. El primer problema que resolví en ella es permitir pasarle los directorios en donde montar la unidad externa, en donde buscar los dispositivos conectados, y el tipo de sistema de archivos que se quiere montar. Todo esto se puede especificar ahora desde la línea de comandos si se desea (si no se indica nada, se utilizan los valores por defecto que comenté en la anterior entrada).

El segundo cambio es añadir una FIFO para poder ejecutar comandos desde el entorno externo al chroot. El principal motivo es para poder ejecutar un apagado ordenado, pues desde dentro del entorno no se puede ejecutar, por ejemplo, un shutdown -h now. Para ello se crea la FIFO /dev/chroot_ext_control, que esperará a recibir algún comando. De momento admite dos:

• halt mata todos los procesos que estén accediendo a algún fichero en la unidad, y una vez hecho esto, la vuelve a montar como sólo-lectura, para que no se corrompan los datos al apagar.
• reboot lo mismo que halt, pero luego reinicia la máquina

Estos comandos se pueden emitir simplemente con echo reboot > /dev/chroot_ext_control o echo halt > /dev/chroot_ext_control.

El nuevo código se puede descargar con este enlace.

Los parámetros que acepta la nueva versión desde la línea de comandos son:

• -o opciones de montaje. La cadena que sigue se añade tal cual al comando mount, junto con -o. Esto permite añadir opciones como noatime.
• -m ruta de montaje. La cadena que sigue indica la ruta donde se montará la unidad externa. Por defecto es /system/debian.
• -t tipo de sistema de ficheros. La cadena que sigue indica el tipo de sistema de ficheros que se pasará a mount. Por defecto es ext4.
• -c ruta de dispositivos. La cadena que sigue indica la ruta donde aparecen los ficheros de dispositivo, como sda1. Por defecto es /dev/block.
• -f ruta y fichero para la FIFO. La cadena que sigue indica la ruta y el fichero para la FIFO de control. Por defecto es /dev/chroot_ext_control.

El motivo de poner la FIFO de control en /dev es que, al ser un sistema de ficheros en RAM, no habrá interferencias con otros posibles ficheros, y además es accesible con el mismo nombre desde dentro y fuera del entorno chroot.

Cambios en el lanzador principal

El script situado en /system/etc/install-recovery.sh también ha cambiado ligeramente. Ahora es así:

#!/system/bin/sh

cp /system/bin/launch_debian /dev
/dev/launch_debian &

El motivo de hacer esto es que ahora launch_debian ya no muere al lanzar el entorno Debian, sino que sigue en marcha para responder a las peticiones de comandos emitidas a través de la FIFO. Eso significa que si queremos actualizarlo no lo podemos hacer directamente, porque el fichero estará bloqueado. Por eso primero copiamos el ejecutable a /dev (que tiene la ventaja de ser un disco RAM, y dado que el ejecutable es muy pequeño, no supone un desperdicio de memoria) y lo ejecutamos desde ahí: de esa forma el ejecutable original nunca se bloquea, y podemos reemplazarlo en caliente y luego reiniciar para que se utilice la nueva versión.

Cambios en el lanzador de la jaula chroot

El script situado en el disco duro, runlinux.sh, también ha cambiado un poco. Ahora es así:

#!/system/bin/sh

# stop the Android system
stop
sleep 1
# stop the daemons to ensure that
# they don't disturb the debian system
# (can't kill them because INIT would
#  relaunch them)
# Also allows to send them to SWAP
busybox killall -SIGSTOP netd
busybox killall -SIGSTOP vold
busybox killall -SIGSTOP displayd
busybox killall -SIGSTOP ueventd
busybox killall -SIGSTOP debuggerd
busybox killall -SIGSTOP rild
busybox killall -SIGSTOP drmserver
busybox killall -SIGSTOP mediaserver
busybox killall -SIGSTOP installd
busybox killall -SIGSTOP servicemanager
# undo changes to kernel variables
echo 0 > /proc/sys/kernel/panic_on_oops
echo 18000000 > /proc/sys/kernel/sched_latency_ns
echo 3000000 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 0 > /proc/sys/vm/overcommit_memory
echo 3000 > /proc/sys/vm/dirty_expire_centisecs
echo 1024 > /dev/cpuctl/apps/bg_non_interactive/cpu.shares
echo 900000 > /dev/cpuctl/apps/cpu.rt_runtime_us
echo 900000 > /dev/cpuctl/apps/bg_non_interactive/cpu.rt_runtime_us
# mount proc, sys, dev, dev/pts, dev/cpuctl and /system
mount -o bind /proc $1/proc
mount -o bind /sys $1/sys
mount -o bind /dev $1/dev
mount -o bind /dev/pts $1/dev/pts
mount -o bind /dev/cpuctl $1/dev/cpuctl
mount -o bind /system $1/android
export HOME=/root
export LD_LIBRARY_PATH=
export PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
# set the Framebuffer devices where standard apps expect them
cp -a /dev/graphics/* /dev
# launch our Debian system
/system/bin/busybox chroot $1 /bin/system.sh

El primer cambio está en los distintos comandos echo XXXXXX >…. Estos comandos pretenden restaurar los valores originales en diversas variables del núcleo. Esto es porque Android está orientado hacia aplicaciones de usuario, por lo que, por ejemplo, le quita prioridad a las aplicaciones en segundo plano. Con estas opciones intento deshacer lo que se cambia en el fichero init.rc. Sin embargo es importante indicar que probablemente lo que cambie dependa de cada fabricante, así que cada uno debe mirar qué es lo que se modifica.

El siguiente cambio es que monto también /dev/cpuctl, algo que se me había pasado.

Por último, monto el directorio /system dentro del directorio android de la unidad montada. De esta manera se tiene acceso al sistema Android desde dentro de la jaula chroot, lo que permite, por ejemplo, actualizar el fichero launch_debian.

(La segunda parte de este artículo está en https://blog.rastersoft.com/?p=1386)

Hace unas semanas me compré un cacharro de tipo AndroidTV (este en concreto). Sin embargo ya tenía claro que no quería tener Android, sino un linux como $DEITY manda. Por eso busqué uno con el mismo chip que mi tablet. Por desgracia esta vez no conseguí que arrancase desde una tarjeta externa (parece que han cambiado algo en el cargador). Pero como a cabezota no me gana nadie, decidí buscar alguna alternativa.

Por supuesto no quería eliminar el Android que ya trae, más que nada por si me lo cargo y acabo con un bonito pisapapeles. Por eso decidí intentar una ruta intermedia: una vez arrancado el sistema, lanzaría un programa que mataría todos los procesos de Android y lanzaría una Debian almacenada en un disco externo, desde un entorno chroot, con su entorno gráfico y todo. De esta manera, si no enchufo el disco el sistema arrancaría Android normalmente, y si lo enchufo, arrancaría Linux.

Obviamente la cosa no es tan sencilla. Para empezar, los diversos procesos de Android se vuelven a lanzar automáticamente si mueren, por lo que no podemos utilizar un simple kill pid. Afortunadamente existen los comandos start y stop que lanzan y detienen todo el entorno gráfico. Para probarlos utilicé adb, disponible en el entorno de desarrollo de Android. Para ello primero lancé el servidor con

sudo ./adb start server

Y luego cada vez que necesitaba una consola en el dispositivo, lo conectaba con el cable USB y lanzaba:

./adb shell

Y efectivamente, si ejecutaba stop el entorno de Android desaparecía, quedando la pantalla congelada. Ejecutando start volvía a arrancar todo. Afortunadamente, aunque mi dispositivo no está completamente rooteado, si es lo suficientemente libre como para que, por defecto, entre como root desde esta shell, además de incluir un busybox con chroot. Con esto ya tengo resuelto el primer gran problema. Es cierto que todavía quedan varios servicios en marcha, como el gestor de red, pero es un problema secundario que ya resolveremos luego.

OJO: el servicio adb en el dispositivo Android tarda un poco en ser lanzado. Si acabáis de arrancarlo, sed pacientes. Por otro lado, a veces la lista de dispositivos USB con Android no está actualizada en Linux, así que es posible que haya que tocar un poco en udev para que reconozca el nuestro.

Autoarranque

Si sólo quisiese lanzar manualmente el nuevo entorno ya tendría el problema resuelto; pero yo quiero un dispositivo que arranque Debian incluso si no estoy (por ejemplo si se va la luz y luego vuelve), por lo que no queda más remedio que meter las narices en el proceso de arranque de Android.

Alguno puede pensar que ir a tan bajo nivel es exagerado, pero hay un motivo: la primera idea que se me ocurrió fue buscar algún programa nativo de Android que en el arranque lance automáticamente un script que yo le pase. Encontré varios, pero fue entonces cuando descubrí que mi cacharro no está rooteado del todo, por lo que ese script no podía lanzar un chroot ni nada por el estilo. Así pues, no queda más remedio que meter las narices más abajo.

Como en cualquier sistema Linux, una vez arrancado el núcleo se ejecuta el proceso init. Pero aquí acaban los paralelismos, porque en Android este proceso es muy diferente del SysV Init: aquí hay un conjunto de ficheros .rc con una serie de indicaciones de qué procesos hay que lanzar, en qué orden, con qué permisos, de qué dependen, y, sobre todo, si es necesario volver a lanzarlos si mueren. Estos ficheros .rc se encuentran en el raíz del sistema de ficheros, y ese es primer problema serio con el que nos encontramos: en general, el sistema raíz es de tipo rootfs. Este sistema de ficheros es un tipo de ramfs, que se inicializa durante el arranque con unos valores predeterminados, y además está montado como sólo lectura. Aunque en principio podemos hacer mount -o remount,rw / para permitir escritura, cualquier cambio que hagamos desaparecerá al reiniciar. La única manera de modificar el sistema de archivos es recompilarlo y grabar la partición entera, y eso es algo que no quiero hacer por el riesgo de cascar el sistema. Sin embargo, en /system tenemos una partición que sí es modificable, porque es de tipo ext4, así que intentaremos meter nuestro autoarranque ahí. En caso de que, por defecto, dicha partición esté montada como sólo lectura, podemos volverla de lectura/escritura con:

mount -o remount,rw /system

y devolverla a sólo lectura con

mount -o remount,ro /system

El formato de los ficheros .rc es relativamente sencillo: si una línea comienza por on XXXXX, las líneas siguientes definen los comandos a realizar cuando ocurra el evento XXXXX. Pero si empieza por service XXXXX, entonces las siguientes líneas definen a dicho servicio XXXXX, que se debe lanzar al inicio. Un ejemplo de servicio sería este:

service console /system/bin/sh
    class core
    console
    disabled
    user shell
    group log

Estas líneas definen el servicio console, que se lanza ejecutando el binario /system/bin/sh. Además, debe lanzarse como usuario shell y grupo log. Si estos dos parámetros no se incluyen se lanza como root.

Una línea especial, que nos interesa especialmente, es oneshot. Cuando un servicio la incluye significa que debe lanzarse una única vez durante el arranque, y si se muere no debe lanzarse de nuevo. En cambio, aquellos servicios que no incluyen oneshot se vuelven a lanzar si mueren. El motivo de explicar esto es que lo que vamos a hacer es buscar un servicio de tipo oneshot, y reemplazar su binario por un script que primero llame al binario original, y luego haga lo que a nosotros nos interese. En mi caso tuve más suerte, y encontré este servicio:

service flash_recovery /system/etc/install-recovery.sh
    class main
    oneshot

Por el nombre, tiene pinta de ser lo que se lanza cuando se borran las preferencias y se quiere dejar el sistema como recién comprado. Si vamos a /system/etc, vemos que no existe el fichero install-recovery.sh, supongo que porque sólo se creará cuando se quieran borrar los datos; pero eso significa que nosotros podemos meter en su lugar un ejecutable o un script y éste se ejecutará como root cada vez que arranque el sistema. Y además, al estar en /system podemos editarlo a nuestro antojo ¡Justo lo que estábamos buscando!

Lanzamiento condicional

Ahora que ya tenemos donde meter nuestro código, la primera idea que se nos viene a la cabeza es montar un sistema Debian en, por ejemplo, /system/debian, escribir un script que monte una copia de proc, sys y dev, y meterlo directamente en /system/etc/install-recovery.sh. Esto tiene varios problemas:

• Las unidades en formato Ext2/3/4 no se montan automáticamente desde Android, por lo que tendríamos que hacerlo a mano.
• Además, si hay varias unidades USB, tendríamos que ver cual es la correcta de todas ellas
• Según como lo hagamos podemos perder por completo el acceso a Android.
• Tendremos el sistema hardcoded, grabado en piedra, y para cambiar cualquier cosa tendremos que volver a entrar en la flash de nuestro dispositivo.

La opción por la que me he decantado es la de disponer de un disco duro externo con el sistema Debian, e incluir en él un pequeño fichero ejecutable con un nombre específico. De esa manera el único cambio que hay que hacer en nuestro sistema Android es añadir un pequeño programa que se lance durante el inicio y que compruebe todas las unidades USB en busca de dicho ejecutable, y si lo encuentra, que lo lance. De esa manera podemos meter ahí toda la magia y reducir al mínimo los cambios a realizar en nuestro dispositivo Android.

Lo primero que hice fue crear un pequeño programa que comprobase constantemente si aparecía un nuevo dispositivo USB; en caso de que así fuese, intentaría montarlo como una partición EXT4 en un punto concreto y ejecutar un fichero runlinux.sh en él. Al principio lo hice todo con comandos shell, pero el resultado era bastante chapucero porque lo que hacía era comprobar de manera periódica (cada cinco segundos) si había dispositivos. Además, cada comprobación implicaba ejecutar varios grep, sed y otros comandos, lo que aumentaba el consumo de CPU. Aunque una vez lanzado el sistema Debian esta comprobación se detenía, sí seguía en marcha mientras se estuviese trabajando en Android. Por eso al final lo reescribí en C y utilizando inotify, de manera que no hace falta realizar una espera activa, sino que el programa sólo se despierta cuando se inserta un nuevo dispositivo. El código de este programa se puede bajar desde aquí. Para compilarlo basta con utilizar el comando

arm-linux-androideabi-gcc launch_debian.c -o launch_debian

El compilador arm-linux-androideabi está disponible en Debian y derivadas en el paquete gcc-arm-linux-androideabi. A continuación hay que copiar el binario a /system/bin en nuestro dispositivo Android, y añadir el siguiente script en /system/etc/install-recovery.sh:

#!/system/bin/sh

/system/bin/launch_debian &

Este script lo que hace es lanzar launch_debian en segundo plano, y éste se quedará esperando a que se conecte un nuevo dispositivo USB con alguna partición EXT4. En caso de que eso ocurra, montará dicha partición (con las opciones noatime y nodiratime; para discos duros normales no es necesario, pero es interesante para unidades flash) e intentará ejecutar el fichero runlinux.sh, pasándole como primer parámetro la ruta donde está montada la partición (por defecto /system/debian), y como segundo parámetro el dispositivo que se ha montado (por ejemplo, sdb2). Una vez que termine de ejecutarse correctamente dicho fichero, launch_debian morirá. Pero si falla la ejecución o no existe dicho fichero, el programa seguirá probando con el resto de dispositivos.

El motivo de poner un script intermedio en lugar de meter el ejecutable directamente en /system/etc/install-recovery.sh es porque así, si por cualquier motivo el sistema Android sobreescribe dicho fichero, puedo recuperarlo fácilmente desde una consola, en lugar de necesitar transferir un binario.

Generando el sistema de ficheros

Ahora que ya tenemos todo listo en el sistema Android queda generar el entorno Debian, que será el que ejecutemos, así como un script que lo lance mediante una llamada a chroot.

Vamos a empezar con el entorno Debian. Para ello formatearemos un disco en EXT3 o en EXT4 y, desde un sistema Debian o derivado (Ubuntu, por ejemplo) bajamos el paquete debootstrap. A continuación montamos manualmente el disco donde queremos generar el sistema (porque, por defecto, los escritorios lo montan con las opciones nodev y noexec, y debootstrap se niega a trabajar en esas condiciones), y desde una línea de comandos teclearemos (asumiendo que el disco donde queremos instalar el sistema base está en /mnt):

sudo debootstrap --arch=armhf --foreign --variant=minbase wheezy /mnt http://ftp.us.debian.org/debian

En este caso estamos instalando Debian wheezy, que es la rama testing a la hora de escribir este artículo. En el futuro puede ser necesario cambiar a otra rama, según se desee.

Una vez ha terminado de instalarse, editamos el fichero etc/resolv.conf para añadir un DNS por defecto. En mi caso he utilizado los de google, pero se puede utilizar cualquiera. Mi fichero quedó así:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
#nameserver 127.0.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4

Ahora desmontamos el disco y lo conectamos a nuestro sistema Android. Luego ejecutamos ./adb shell para entrar en él, y procederemos a montar la unidad donde instalamos el sistema en, por ejemplo, /mnt/usb_storage. Una vez hecho esto, y tras asegurarnos de que tenemos conexión a internet desde nuestro dispositivo Android, ejecutamos los siguientes comandos (también en nuestro dispositivo Android mediante adb shell) para entrar en el entorno chroot y terminar la instalación del sistema base:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH
export HOME=/root
export LD_LIBRARY_PATH=
mount -o bind /proc /mnt/usb_storage/proc
mount -o bind /sys /mnt/usb_storage/sys
mount -o bind /dev /mnt/usb_storage/dev
mount -o bind /dev/pts /mnt/usb_storage/dev/pts
busybox chroot /mnt/usb_storage /bin/bash -l
debootstrap/debootstrap --second-stage

Con esto terminamos la instalación del sistema base, pero ahora toca configurarlo. En primer lugar vamos a configurar APT para poder bajar paquetes y demás. Para ello salimos del entorno chroot, desmontamos el disco, lo montamos en nuestro ordenador y editamos el fichero /etc/apt/sources.list para añadir las siguientes líneas:

deb http://ftp.de.debian.org/debian wheezy main contrib non-free
deb http://ftp.de.debian.org/debian wheezy-updates main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free

Ahora podemos volver a montar el disco en nuestro sistema Android y volver a lanzar el entorno chroot. Vamos a instalar ahora las herramientas básicas que nos faltan para terminar de configurar el sistema con autoarranque y poder dedicarnos a jugar con él. Para ello vamos a instalar el servicio de gestión de redes, para tener acceso a internet completo, el servidor SSH para poder gestionar todo de manera remota, ifconfig, ping, el cliente DHCP y un editor de textos (normalmente uso nano pero da problemas desde adb; por eso uso vim de manera temporal) para editar los últimos ficheros necesarios para que todo funcione automáticamente. Para ello, una vez que estamos de nuevo dentro de la jaula chroot (¡¡¡no olvidarse de los exports!!!), ejecutamos los siguientes comandos:

apt-get update
apt-get dist-upgrade -y
apt-get install ifupdown openssh-server net-tools vim iputils-ping isc-dhcp-client

El siguiente paso es crear el fichero runlinux.sh, que será ejecutado desde nuestro entorno Android por launch_debian. Este script preparará el entorno para lanzar una sesión chroot, y debe contener las siguientes líneas:

#!/system/bin/sh

# stop the Android system
stop
sleep 1
# stop the daemons to ensure that
# they don't disturb the debian system
# (can't kill them because INIT would
#  relaunch them)
# Also allows to send them to SWAP
busybox killall -SIGSTOP netd
busybox killall -SIGSTOP vold
busybox killall -SIGSTOP displayd
busybox killall -SIGSTOP ueventd
busybox killall -SIGSTOP debuggerd
busybox killall -SIGSTOP rild
busybox killall -SIGSTOP drmserver
busybox killall -SIGSTOP mediaserver
busybox killall -SIGSTOP installd
busybox killall -SIGSTOP servicemanager
# mount proc, sys, dev and dev/pts
mount -o bind /proc $1/proc
mount -o bind /sys $1/sys
mount -o bind /dev $1/dev
mount -o bind /dev/pts $1/dev/pts
export HOME=/
export LD_LIBRARY_PATH=
export PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
# set the Framebuffer devices where standard apps expect them
cp -a /dev/graphics/* /dev
# launch our Debian system
/system/bin/busybox chroot $1 /bin/system.sh

Lo primero que hace este script es detener el entorno Android, de manera que liberamos la memoria consumida por éste. A continuación envía una señal SIGSTOP a diversos procesos de Android que siguen en marcha, como el gestor de red. Esto es necesario porque, si no, interferiría con las herramientas de Debian. Por otro lado, como ya expliqué antes, no podemos matarlos porque el sistema init los lanzaría de nuevo.

El siguiente paso consiste en montar proc, sys, dev y dev/pts en el sistema Debian. Vemos que utiliza el primer parámetro, pues launch_debian pasa ahí la ruta donde se montó la partición.

A continuación inicializamos las variables de entorno. Vemos que borramos LD_LIBRARY_PATH. Esto es así porque algunos Android la utilizan para añadir otras rutas con bibliotecas, pero en nuestro caso nos interferiría.

Luego se copian todos los ficheros de dispositivo situados en /dev/graphics a /dev. Esto es así porque en Android los dispositivos framebuffer están en esa ruta alternativa, por lo que tenemos que copiarlos a donde las aplicaciones de Linux esperan encontrarlos.

Por último ejecutamos nuestro chroot. Cabe indicar que es necesario poner la ruta completa de busybox porque hemos sobreescrito la variable de entorno PATH. Vemos que lanzamos el script /bin/system.sh. Este script será quien lance todo lo que queramos lanzar en nuestro sistema Debian (servidor X, demonios…). En el caso actual lo que hice fue poner en él las siguientes líneas:

#!/bin/bash

service networking restart
service ssh restart

Con esto inicializo la red (necesario si el disco estaba enchufado al encender el dispositivo Android, porque launch_debian lo detectará tan rápido que no dará tiempo a que arranque Android y configure la red), y lanzo el servidor ssh, que me permitirá entrar de manera remota. Para que estos dos comandos funcionen, sin embargo, es imprescindible configurar algunas cosas primero:

• Para el servicio networking es necesario editar el fichero /etc/network/interfaces y configurar ahí nuestros dispositivos de red. Teniendo en cuenta la gran cantidad de tutoriales que hay al respecto, no voy a añadir mucho más.

• Para que ssh funcione, lo primero que es necesario es ponerle clave al usuario root. Para ello utilizamos el comando passwd. Una vez hecho esto editamos /etc/ssh/sshd_config para ajustar la configuración.

Con todo esto ya tenemos el sistema base configurado y listo. Salimos de nuestra jaula chroot, ejecutamos sync por si acaso, y reiniciamos nuestro dispositivo Android. Si todo va bien, el entorno Android no debería ni siquiera arrancar, y deberíamos poder entrar mediante ssh.

El siguiente paso será añadir BitTorrent, servidor FTP y algún cliente multimedia para utilizarlo como equipo de salón, pero eso lo dejo para futuras entradas.

Actualizado. Después de mucho pelearme con mi tablet, finalmente he conseguido que funcionen casi todos los dispositivos. También he pulido el proceso de instalación de Linux; de hecho hay bastantes cosas que cambiar del artículo anterior, así que vamos allá.

El fichero SCRIPT.BIN

En primer lugar quería disponer del fichero script.bin original de mi tablet, y no de uno creado para otro dispositivo, porque obviamente podía haber algún parámetro (velocidad de memoria, puertos de dispositivos, etc) que tuviese un valor diferente, evitando que funcionase algún dispositivo. De hecho, una vez que conseguí utilizarlo, el sonido funcionó automáticamente (antes no detectaba ninguna tarjeta de sonido).

El proceso para obtener dicho fichero bin no fue sencillo: dicho fichero está en la flash interna de la tablet, pero por desgracia no tenía acceso a ella desde Linux (no detecta dicho dispositivo) ni desde Android (lo detecta, obviamente, pero no tengo permisos de acceso por no tener la tablet rooteada. Además, al ser la partición de arranque, no se monta una vez lanzado Android, por lo que tampoco está disponible desde éste). Tras muchos intentos encontré la solución: utilizar el ADB (Android Debug Bridge). Esto permite acceder a un dispositivo Android desde un PC. Para ello, una vez instalado el kit de desarrollo de Android, basta conectar la tablet al PC a través de un puerto USB, ir al directorio sdk/platform-tools y ejecutar:

    sudo ./adb start-server
    ./adb shell
    cat /dev/block/mmcblk0p1 > punto_de_montaje_de_tarjeta_SD/particion1.img
    exit
    sudo ./adb kill-server

El primer comando lanzará como root el servidor ADB, que se conectará a nuestro dispositivo, y el segundo lanzará una shell como root en él. El tercero, ejecutado ya desde la shell del dispositivo, volcará la primera partición de la flash en el fichero particion1.img de la tarjeta SD. Por último, salimos de la shell y desactivamos el servidor ADB.

En ocasiones adb no encuentra nuestro dispositivo. Si tecleando ./adb devices no aparece ningún dispositivo detectado, es posible que adb no tenga a nuestro fabricante en su lista. Para añadirlo manualmente hacemos un lsusb, y vemos el identificador de nuestra tablet. Digamos que es AAAA:BBBB (dos números en hexadecimal de cuatro cifras cada uno). Sólo tenemos que editar ~/.android/adb_usb.ini y añadir en él 0xAAAA, reiniciar el servidor adb, y listo.

Ahora sólo tenemos que llevar el fichero particion1.img a un PC con linux y montar dicha partición, por ejemplo en /mnt:

    sudo mount -o loop particion1.img /mnt

Ahí encontraremos el fichero script.bin, que podremos convertir en un fichero .fex mediante la utilidad bin2fex, que encontraremos en el repositorio sunxi-tools. De hecho es necesario hacerlo para poder hacer un par de modificaciones, sin las que nuestro Linux no arrancaría desde la tarjeta SD. En concreto éstos son los cambios:

@@ -12,7 +12,7 @@
 pll4_freq = 960
 pll6_freq = 720
 power_start = 0
-storage_type = 2
+storage_type = 1

 [pm_para]
 standby_mode = 0
@@ -445,7 +445,7 @@
 sdc_wp =

 [mmc2_para]
-sdc_used = 1
+sdc_used = 0
 sdc_detmode = 3
 bus_width = 8
 sdc_cmd = port:PC06<3><1><3><default>
@@ -510,7 +510,7 @@
 usb_id_gpio =
 usb_det_vbus_gpio =
 usb_drv_vbus_gpio = port:power203<1><0><default><0>
-usb_host_init_state = 0
+usb_host_init_state = 1

 [port_pm]
 restrict_1a = 0

El primero cambia el tipo de almacenamiento de Flash a SD. El segundo especifica que no se active la memoria Flash interna (si se activa, no arranca el sistema). Por último, el tercero activa desde el principio el segundo USB, necesario para que funcione la red WiFi.

Existe una lista con todas las opciones de un fichero FEX, útil si se quieren hacer más cambios manuales.

Una vez hechos estos cambios ya podemos generar el fichero script.bin final, siguiendo el método indicado en el artículo anterior.

El kernel

En el núcleo también hay que hacer algunos cambios. Para empezar, hay que utilizar la versión 3.4, en lugar de la 3.0, porque es la que tiene soporte para la tarjeta de red:

    git clone -b sunxi-3.4 https://github.com/linux-sunxi/linux-sunxi linux-3.4-sunxi
    cd linux-3.4-sunxi

De todas formas, el chip que lleva esta tablet es el Realtek RTL8188etv. Aunque en teoría es compatible con el driver para la familia RTL8188, en la práctica hay que añadir una línea para que reconozca el identificador USB de este chip concreto. Aunque ya envié el parche a la lista de correo, lo añado aquí porque no se cuanto tardarán en añadirlo:

diff --git a/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c b/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
index 5f4390a..df9d488 100644
--- a/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
+++ b/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
@@ -185,7 +185,8 @@ static struct usb_device_id rtw_usb_id_tbl[] ={
 #endif
 #ifdef CONFIG_RTL8188E
        /*=== Realtek demoboard ===*/           
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8179)},//Default ID        
+       {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)},//rtl8188etv ID (szenio 1207 tablet)
 #endif
        {}      /* Terminating entry */
 };

Una vez aplicado este cambio de una única línea, podemos ya proceder a configurar el núcleo. Para ello partimos de la configuración genérica para el A13:

    make ARCH=arm a13_defconfig
    make ARCH=arm menuconfig

Estas son las opciones que he modificado:

    General Setup
        POSIX message queues=Y
    Device Drivers
        Network Device Support
            Ethernet (10 or 100Mbit)=N
            Wireless LAN
                Realtek 8188E USB WiFi=M
        Character Devices
            Non-standard serial port support=N
            Serial drivers
                8250/16550 and compatible serial support=N
        Graphics support
            Console Display driver support
                Map the console to the primary display device=Y
            Bootup logo=Y
    Security Options
        Enable the securityfs filesystem=N

Una vez hecho, podemos ya proceder a compilarlo, pero con el compilador que utilice la gnueabihf (que utiliza coma flotante por hardware, en lugar de la gnueabi, como hacía en el artículo anterior). Para ello primero necesitamos instalar esta versión del compilador:

    sudo apt-get install gcc-4.7-arm-linux-gnueabihf gcc-arm-linux-gnueabihf

y ya podemos compilar el núcleo en sí:

    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage
    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=out modules
    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=out modules_install

Los ficheros boot.cmd y boot.scr

El último cambio respecto al artículo anterior está en el fichero boot.cmd (y su fichero hijo boot.scr). Este fichero contiene los parámetros de arranque del núcleo, y es básicamente un script para U-Boot. En nuestro caso, crearemos el fichero boot.cmd en la partición VFAT de nuestra tarjeta SD con este contenido:

    setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 ${extra}
    fatload mmc 0 0x43000000 script.bin
    fatload mmc 0 0x48000000 uImage
    bootm 0x48000000

y lo compilaremos con:

    mkimage -C none -A arm -T script -d boot.cmd boot.scr

Y listo. Si en algún momento queremos cambiar las opciones de arranque de nuestro núcleo, sólo tendremos que editar el fichero boot.cmd, añadirlas en la primera línea y recompilarlo. Existe una página con todas las opciones del núcleo específicas de sunXi.

Encender y apagar el sistema

De momento no está activa la gestión de energía, por lo que si se hace un halt o un shutdown -h now, el sistema parecerá apagarse, pero en realidad seguirá encendido. En estos casos, para apagarlo «de verdad» es necesario mantener pulsado el botón de encendido durante seis o más segundos.