Raspberry Pi crear initramfs para usar UUID u otras features

Estas líneas surgieron a propósito de una incomodidad: no poder usar UUID para identificar la partición del sistema de archivos raíz en mi Raspberry Pi. Eso me llevó a la sospecha de que para hacerlo funcionar sería necesario crear un sistema inicial de archivos en RAM, más conocido como initramfs. Siguen aquí los pasos para crear esa configuración, que fueron mucho más sencillo de lo que yo esperaba.


Estas notas son un borrador ya que resta probar que la configuración sea estable, pero por el momento viene funcionando sin problemas.
Aclaración: si vas a hacer esto, está claro que es por tu cuenta y riesgo. Para hacerlo, es mejor contar con una SD de pruebas, hacer backup y todo lo que consideres apropiado para la integridad de tus datos.



Estas pruebas me llevaron a reforzar más aún un argumento que se está convirtiendo en mi credo: "La pequeña Raspberry Pi se apoya en los hombros de un gigante", ese gigante es Linux, pero también Debian porque en el caso de Raspbian la Raspberry Pi es heredera de las dos décadas de trabajo de la comunidad mundial de Debian. Lo digo, porque para que crear un initramfs sea una tarea simple es porque se pudieron usar las herramientas initramfs-tools de Debian, encargadas de la magia de la trastienda de la creación del initramfs. Sin Linux la Raspberry Pi sería un pedacito de fierro del tamaño de una tarjeta de crédito, y poco más.

Incomodidad inicial

Para experimentar y entender cómo funcionaba el proceso de boot de la Raspberry Pi decidí crear una tarjeta SD (de 512 Mb que me facilitara mi amigo @DiegoRAM). Esa tarjeta SD sólo contiene la partición /boot, que guarda el firmware Raspberry Pi y el kernel Linux. Por cómo es la arquitectura de la Raspberry Pi, hay que recordar que es obligatoria usar una tarjeta SD, con sistema de archivos tipo VFAT.
La partición raíz la instalé en un USB stick de 8Gb ¿El motivo? Sólo experimentar, per-jodere o "Just for fun". Para ciertas configuraciones, en las que se requiera uso intensivo de escritura en el siste de archivos, ej un servidor web que usara un base de datos en la misma Raspberry Pi resultaría conveniente "aislar" las particiones de datos (la raíz y quizá otros F.S como /var) fuera de la tarjeta SD de inicio.
Queda claro entonces que para estas pruebas usé un usb stick (8Gb) pero podría haberse usado un disco duro, por ejemplo.

Cómo crear los sistemas de archivos y copiar los archivos no lo detallo aquí, para no extenderme demasiado. Es simplemente usar herramientas *nix estándar como fdisk, mkfs... rsync. En resumen, tenemos dos particiones creadas, la /boot en la SD 512 Mb y la raíz (/) en el USB stick, ambas con los archivos estándares contenidos en la iso de Raspbian.

La configuración por defecto de los archivos que componen el firmware RasPi y el kernel trae un arhivo llamado cmdline.txt que es el encargado de pasarle los parámetros al kernel, en momento de boot:

pi@raspberrypi ~ $ cat /boot/cmdline.txt.ori
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

boot= le indica al kernel dónde debe buscar el File System raíz (/). Por defecto, en la imagen de Raspbian ese F.S está en la segunda partición de la SD, como en este caso ésta no existe le indicamos que la busque en la partición del USB stick:

pi@raspberrypi ~ $ cat /boot/cmdline.txt.ori
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline rootwait

También debe alterarse el /etc/fstab:

proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
#/dev/sda1 / ext4 defaults,noatime 0 1
UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that

Como se ve, el montaje de la partición raíz original ( /dev/mmcblk0p2 ) está comentado y reemplazado por el FS contenido en el usb stick.


Mientras hacía esto percibí que muchas personas que utilizan un sistema de archivos externos en la Raspberry Pi en realidad utilizan la partición raíz /dev/mmcblk0p2 (en cmdline.txt) y luego montan el FS raíz en un segundo paso en /etc/fstab. Esto no tiene nada de malo, sólo que agrega un paso extra al proceso de boot. En caso de que el FS root en la SD fallara la RasPi no iniciaría.

Hasta este punto todo funcionaba bien la RasPi booteaba sin problemas, todo funcionaba como de costumbre.
Bien, he aquí cómo se originó el problema. No habría mucho problema siempre y cuando en cmdline.txt pasaramos al kernel el parámetro root=/dev/sda1 o cómo el kernel se dignase de identificar nuestro usb stick. Quien lleve un tiempo usando linux, discos scsi, s-ata o pendrives conocerá, algun problema puede ocurrir: el nombre del dispositivo puede cambiar. Ejemplo si alguna vez booteáramos la RasPi con otro pendrive conectado nada asegurará que nuestro usb stick (o hd) siga llamándose /dev/sda1.
Por eso yo quería usar UUID Universal Unique Identifier (véase http://en.wikipedia.org/wiki/Uuid ). Ese es el modo en que el kernel, en cualquier arquitectura puede identificar un dispositivo de forma más confiable.

Los UUID se pueden ver con blkid:

pi@raspberrypi ~ $ blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="7709-6D92" TYPE="vfat"
/dev/sda1: LABEL="rootfs" UUID="fa5e974b-7360-45c3-9f35-67a090f34bdd" TYPE="ext4"

Aquí vemos que mi FS en el usb stick tiene la UUID=fa5e...blah...blah.

La solución debía ser simple, tan simple como agregar la UUID en el cmdline.txt, inclusive así se menciona en ciertos posts:

cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd rootfstype=ext4 elevator=deadline rootwait rootdelay=5

Pero... Así la cosa no funcionaba. El bootloader (configurable a través de cmdline.txt) le pasa el parámetro al kernel, pero este no puede identificar la partición por su UUID. Una vez que el kernel se cargaba, no hay problema en /etc/fstab ese problema no existe.
Luego de investigar un poco llegué a la conclusión que el bootloader no podía pasar así por así la UUID al kernel. Hacía falta un FS de inicio en RAM, más conocido como initramfs o initrd según su variante.
Para llegar a esta conclusión este thread fue fundamental http://forum.stmlabs.com/showthread.php?tid=9966.


Mundo PC / Mundo RasPi


La mayoría de las distribuciones actuales de Linux/GNU utilizan entre las diferentes etapas del proceso de inicio o boot un sistema de archivos en memoria RAM, cuyo objeto es cargar módulos del kernel indispensables para poder continuar con el proceso. De esa forma, la "pisada" del kernel en memoria se reduce porque sólo se van cargando los módulos bajo demanda.
Por defecto, el firmware Raspberry Pi no utiliza un initramfs. Para usar UUID había que crearlo.

Como el kernel stock (por lo menos el de raspbian) no trae por defecto el soporte para initramfs había que compilarlo:

UPDATE 10/10/2013: Hicimos un pedido a los mantenedores del firmware y el kernel Raspberry Pi https://github.com/raspberrypi/linux/issues/392 y muy amablemente y en poquísimos días nos agregaron el feature en el stock kernel de testing. Eso simplifica mucho este proceso porque no se requiere ya recompilar el kernel y además, con sucesivos rpi-updates no vamos a perder el soporte para initrd.
Para bajar el stock kernel de pruebas (3.10.15+) al momento de escribir estas líneas:

# export BRANCH="next" && rpi-update

Luego de clonar el git de desarrollo debe instalarnos el kernel de la rama "next" (testing) con el soporte para initrd, que luego del reboot se puede verificar con:

$ zcat /proc/config.gz | grep -i initr
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""

El que opte por usar este kernel stock, puede seguir con los pasos descritos en "Creación del initramfs"

Claro, el que por algún motivo lo desee puede seguir construyendo su kernel "custom", con los pasos descriptos abajo.

1) Compilar

En elinux.org, el site con la mejor documentación sobre Rasberry Pi se describe el paso-a-paso para compilar un kernel, inclusive haciendo cross-compilling: http://elinux.org/RPi_Kernel_Compilation
Siguiendo el paso-a-paso del roadmap de la doc que traduzco abajo, compilar en un Debian 386 fue mucho más sencillo de lo que esperaba:


1) Obtener el código fuente del kernel más reciente, con las características del Raspberry Pi (https://github.com/raspberrypi/linux) en este caso bajé el tarball: $wget https://github.com/raspberrypi/linux/archive/rpi-3.6.y.tar.gz
2) Establecer la variable del entorno KERNEL_SRC que apunte al lugar del código fuente: ( e.g. export KERNEL_SRC=/home/me/linux/ )
3) Obtener el compilador para ARM variante raspberrypi (git clone https://github.com/raspberrypi/tools)
4) Establecer variable de entorno CCPREFIX para apuntar a la localización del las herramientas de compilación ( e.g. export CCPREFIX=/home/me/tools/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi- )
5) Desde el directorio donde se ubica el kernel, limpiar con "make mrproper"
6) Copiar la config default de un raspbian, copiando el archivo /proc/config.gz desde un Raspbian corriendo (porque el fs /proc corre en memoria).
7) En el directorio del fuente del kernel zcat config.gz > .config. Y correr "ARCH=arm CROSS_COMPILE=${CCPREFIX} make oldconfig"
8) Modificar la configuración del kernel ya sea alterando .config file o usando "ARCH=arm CROSS_COMPILE=${CCPREFIX} make menuconfig". Deberemos buscar la opción para habilitar initramfs, bajo la sección "General Setup" como se puede ver en la imagen.

9) Construir el nuevo kernel usando "ARCH=arm CROSS_COMPILE=${CCPREFIX} make" (ir por una cervecita)
10) Establecer variable de entorno MODULES_TEMP para apuntar a la localización del fuente ( e.g. export MODULES_TEMP=/home/me/modules/ )
11) Aislar los módulos del nuevo kernel usando "ARCH=arm CROSS_COMPILE=${CCPREFIX} INSTALL_MOD_PATH=${MODULES_TEMP} make modules_install"
12) Desde la ubicación de las herramientas de compilación en el directorio mkimage correr: "./imagetool-uncompressed.py ${KERNEL_SRC}/arch/arm/boot/zImage"
13) Mover el kernel resultante como kernel.img al directorio /boot/ de la raspberry Pi, previamente habiendo guardado una copia del original (mv /boot/kernel.img /boot/kernel.img.stock)
14) Empaquetar los módulos en un archivo (ej. tar) para que queden en el top-level de la jerarquía, con la estructura como sigue:
./firmware
./firmware/brcm
./firmware/edgeport
./firmware/emi26
...
./modules
./modules/3.6.11+
./modules/3.6.11+/kernel
./modules/3.6.11+/kernel/lib
./modules/3.6.11+/kernel/fs
...
15) Mover el archivo con los módulos al directorio raiz de la raspberry Pi y extraerlos, de modo que se sobre-escriban en /lib/firmware y /lib/modules. Previamente hacer backup de esos directorios.
16) Esto no fue necesario porque ya tenía el firmware en /boot (git://github.com/raspberrypi/firmware.git)

17) Transferir el contenido del directorio firmware/hardfp/opt al directorio /opt de Raspberry pi.
18) Reboot de la Raspberry Pi


Creación del initramfs


Ahora se debe crear el initramfs, que gracias a las herramientas provistas por Rasp(DE)bian resulta muy sencillo.

Si no está instalado en la Raspberry vamos a precisar el paquete initramfs-tools:

# aptitude install initramfs-tools

Habiendo booteado con el kernel "custom", verificamos el soporte para initramfs:

root@raspberrypi:~# uname -r
3.6.11

root@raspberrypi:~# zcat /proc/config.gz | grep -i initr
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""

Nos muestra que este kernel fue compilado con el parámetro de soporte para initrd.

Entonces, a crear la el FS:

# update-initramfs -c -k `uname -r` -v

Aquí el único cuidado es ingresar la versión del kernel "destino" del fs init. Si ya booteamos con el kernel que vamos usar podemos usar uname -r, si no más vale ingresar la versión del kernel a mano.

Eso creará el archivo /boot/initrd.img-3.6.11

El contenido del F.S de inicio se puede ver fácilmente con:

root@raspberrypi:~# lsinitramfs /boot/initrd.img-3.6.11 | less

Ahora debe alterarse el archivo config.txt del firmware Raspberry Pi para usar initramfs, agregamos esta línea:

# Test de initramfs, generado con initramfs-tools de DEBIAN
initramfs initrd.img-3.6.11 followkernel

A pesar de que hay cierta controversia en este punto, si al parámetro initramfs debe pasarsele una direccion
de memoria donde cargar el f.s, la opción followkernel funcionó. Aclaro, usando la versión más reciente del
firmware.


Ahora boot usando UUID (que no funcionaba sin el initrd):

pi@raspberrypi ~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1
root=UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd rootfstype=ext4 elevator=deadline rootwait rootdelay=5

Podemos verificar que haya arrancado:

pi@raspberrypi ~ $ dmesg | grep -i uuid
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
bcm2708.boardrev=0xd bcm2708.serial=0xe90f78bb smsc95xx.macaddr=B8:27:EB:0F:78:BB
sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1
root=UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd rootfstype=ext4 elevator=deadline rootwait rootdelay=5

Hacerlo requiere un cierto conocimiento y tener un background con Linux, los scripts de Debian initramfs-tools hicieron la cosas mucho más sencilla de lo que habría sido crear un initrd de la nada.

Algo que habrá que tener en cuenta, a partir de este momento habrá que tener cuidado con rpi-update, porque seguro va a sobreecribir el kernel, y los archivos de config.












Continuar »

Montar partición contenida en imagen

Las particiones contenidas en una imagen pueden extraerse con la herramienta dd, pero es más eficaz montarlas con la opción loop y offset de mount. Esto puede servir para ver o "trabajar" a partir de las imágenes de Raspbian u otras distros para Raspberry Pi.



En este ejemplo trabajamos con la imagen 2013-07-26-wheezy-raspbian.img, de raspbian.

$ /sbin/fdisk -ul 2013-07-26-wheezy-raspbian.img
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


Disk /mnt/backup/RaspberryPi/raspbian_img/2013-07-26-wheezy-raspbian.img: 1 GB, 1932940800 bytes
255 heads, 63 sectors/track, 235 cylinders, total 3775275 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/mnt/backup/RaspberryPi/raspbian_img/2013-07-26-wheezy-raspbian.img1 8192 122879 64228
c FAT32 LBA
Warning: Partition 1 does not end on cylinder boundary.
/mnt/backup/RaspberryPi/raspbian_img/2013-07-26-wheezy-raspbian.img2 122880 3788799 1831410
83 Linux
Warning: Partition 2 does not end on cylinder boundary.

Las opciones a fdisk: -u indica que use como unidad bloques y -l lista.

Lo que nos interesa son los sectores de inicio ("Start"), para pasarselos a mount con el parámetro offset. Vemos que el sector de inicio de la particion de boot (FAT32) es 8192. Ese número lo multiplicamos por 512 (el tamaño de cada bloque). Nos da: 4194304.

Entonces, como root montamos la particion:

Creamos los puntos de montaje:

mkdir boot raiz

Y montamos la partición de boot de raspbian, que contiene todo el firmware y la imagen del kernel:

# mount -o ro,loop,offset=4194304 -t auto 2013-07-26-wheezy-raspbian.img boot

# ls boot/
bootcode.bin cmdline.txt config.txt fixup_cd.dat fixup.dat fixup_x.dat issue.txt kernel_emergency.img
kernel.img start_cd.elf start.elf start_x.elf

Ahora la raiz de Raspbian:

# mount -o ro,loop,offset=62914560 -t auto 2013-07-26-wheezy-raspbian.img raiz/

Véase que offset=62914560 viene de multiplicar el sector de inicio de la partición 122880 * 512.

# ls raiz/
bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp
usr var

Veamos los tamaños de las particiones:

# df -h boot/
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/loop0 56M 19M 38M 33% /mnt/backup/RaspberryPi/raspbian_img/bootcode

La de boot tiene 56M aprox. Y la raiz: 1,8G:

# df -h raiz
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/loop1 1,8G 1,4G 266M 85% /mnt/backup/RaspberryPi/raspbian_img/raiz

Continuar »

40 años de video juegos en el centro de Buenos Aires

El museo de la informática ICATEC, que desde hace pocos meses abrió su sede propia -antes realizaba muestras itinerantes- presenta al público durante el mes de agosto la muestra "Play The Game" un recorrido por las distintas generaciones de consolas de videojuegos y computadoras. La propuesta incluye la posibilidad de poder jugar con juegos corriendo sobre el hardware original, como la famosa Nintendo NES, que a fines de los '80 popularizó el Mario Bros.



Sobre la muestra conversamos en la columna de Tecnología en "Dinero por nada", programa de Radio América AM 1190 Khz, que dirigen Horacio Riggi y Julieta Camandone.

La cita es en Tucumá 810, Capital Federal. Horario de apertura al público:

Jueves y Viernes de 15 a 20 horas
Sábados de 14 a 19 horas
Bono contribución: $ 10

Site: http://www.museodeinformatica.org.ar/ Continuar »

Play the game: 40 años de video juegos

Play the game, es el nombre que la gente de ICATEC, la Fundación Museo de Informática, Computadoras y Accesorios Tecnológicos dio a la muestra que está abierta al público durante todo el mes de agosto.

Allí podrán verse y jugar con una pléyade de consolas organizadas en cuatro generaciones.

Pese a mis años, no había conocido la legendaria Nintendo NES original más que en fotos y por los emuladores para PC. En cambio conocí uno de sus clones más o menos "piratas", el Family Game, que hace poco cumplió 30 años. Por estos pagos, el family fue popular de veras allá por comienzos de los años '90.

Hoy, los niños pudieron jugar con muchas de las consolas que se exponen en el museo de la informática ICATEC. Curiosamente, les llamó la atención el bucólico pong que se veía en una tele blanco y negro. Para niños chicos, eso debe ser algo así como un fósil, pero aún en movimiento. Posiblemente sea también una muestra del poder de la abstracción, es decir, que quizá jugar un rato con "algo" (dos rectángulos y un cuadradito) que poco tienen de analógico con un tenis quizá tenga algo de diversión aún. Aunque sea por un rato.

O al menos, para generaciones acostumbradas al hiper-realismo de la representación de los videojuegos actuales eso debe ser sin dudas sumergirse en un pasado arcaico y abstracto.


La muestra

La muestra está organizada en cuatro generaciones de consolas. La primera, en la lejana década del '70 tenía como exponentes a consolas como la Atari Pong, como se la puede ver en la imagen de abajo

Además la muestra cuenta con muchas otras Atari, de fines de los '70

como la mítica y exitosísima 2600. De la que recuerdo que un amigo de primaria tenía una y nos pasabamos alternando fútbol y consola.
Digresión: Atari tenía un CEO ultravisionario e inteligentísimo, Nolan Bushnel que a fines de los años '70 acogió -y toleró- al jóven Steve Jobs.
Entre los fichines, el salón del museo tiene al mítico Tetris.

No faltan las computadoras "hogareñas" de los '80, que se usaban casi exclusivamente como consolas, como las Commodore 64 y 128, o las MSX.
Entre las perlas, hay muchas. Pero me sorprendió la historia de la última consola de Atari: la Jaguar, que abrió el camino a las de la siguiente generación como la Playstation de Sony. La Jaguar de Atari fue lanzada en 1993 y tenía un hardware descomunal:

Sus competidores Sega y Nintendo venían ganandole a Atari más y más cuota de mercado. Con la Jaguar Atari intentó acortar la brecha. Jaguar funcionaba a 64 bits, cuando sus competidoras seguían con 16 bits. En realidad conseguían los 64 bits usando 5 procesadores de 32 bits contenidos en dos chips que funcionando en paralelo y un coprocesador Motorola 68000, una GPU a 26,591Mhz funcionando a 26,591 MIPS, un bus de datos de 64 bits y una memoria DRAM de 2MB.

Esas y otras sorpresas quizá le depare al visitante la muestra "Play the Game". Vale la pena visitarla. La cita es durante todo el mes de agosto, en Tucumán 810, en el centro porteño. Está abierto los jueves y viernes de 15 a 20 hs y los sábados de 14 a 19 hs.

Cabe destacar que el museo es iniciativa de entusiastas y expertos en preservar el parque informático del país para futuras generaciones. Se mantienen con el aporte de empresas y las donaciones de particulares. El bono contribución es de $10.


Continuar »

Gabinete para Raspberry Pi

A estas alturas la Raspberry Pi no necesita mayores presentaciones, porque se ha vuelto bastante popular.

Para aquellos que no la conozcan aún, la Raspberry Pi es una SBC (Single Board Computer) del tamaño de una tarjeta de crédito aproximadamente. Fue lanzada en Gran Bretaña a principios de 2012. Si bien su hardware está quedando un poquito antiguo (viene con una CPU ARM11, de la arquitectura ARMv6) lo más revolucionario es su precio: 35 dólares estadounidenses.
Aquí muestro un gabinete estándar que fue adaptado para alojar la Raspberry Pi en su interior junto con un hub usb, periférico indispensable.

Por su precio y tamaño tiende a pensarse que la Raspberry Pi es la mejor opción para sistemas embebidos o un appliance que tienden a correr un número limitado de aplicaciones. No tengo nada contra eso, pero no hay que olvidar que la Raspberry Pi es una computadora de uso general, y por lo tanto sus usos pueden ser sumamente variables, pero en todos los casos aprovechando las capacidades que ofrece GNU/Linux: ser un sistema multiusuario, multitarea y, hasta donde sé, multiproceso (con algunas limitaciones) Véase: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=5326
Creo, sinceramente, que una vez que uno definió las "aplicaciones" o si hará de su RasPi un appliance o una compu de uso general, uno tiene que encontrar el gabinete que mejor se adapte a la función (ahora que lo escribo esto parece super Bauhaus loco).

La idea inicial de este proyecto fue: intentar hacer un gabinete más o menos del tamaño de un thinclient, que en su interior tuviera la Raspberry Pi, con su tarjeta SD algo más protegida que en los gabinetes estándar y un hub USB. Éste último es el periférico indispensable, porque no hay que perder de vista que la corriente máxima que puede ofrecer cada puerto USB es de 500 mA (digamos algo menos), y mucho más que esa corriente no puede circular por el circuito de protección de la RasPi. El síntoma más evidente de problemas de alimentación o una fuente insuficiente suele ser cuelgues inesperados de la RasPi. Otro punto al que hay que prestarle atención es que algunos cables USB suelen ser muy malos, porque sus conductores son extremadamente delgados, lo que produce que a mayor consumo mayor sea la caída de tensión en el cable. Después de todo todo conductor se comporta como una resistencia que responde a las leyes del viejo Ohm.
El único requisito que me impuse al comenzar es que no modificaría en nada la placa original de la RasPi. Si quisiera cambirla de gabinete sólo la tendría que desatornillar y a otra cosa. Como contrapartida, esa decisión implica ocupar más espacio en el interior del gabinete.

Mi proyecto original era usar un gabinete de aluminio, pero para esta primera RasPi opté por uno plástico. La verdad es que es muy sencillo trabajar. El gabinete lo compré en http://www.gabiart.com.ar.

La verdad que diseño de la RasPi complica bastante hacer algunos moddings, ponerla en gabinetes que no sean los estándares. La razón principal: que tiene conectores de I/O en tres de sus caras, y en la restante el zócalo de la tarjeta SD. Como el objetivo era no desoldar nada de la placa, lo que hice fue hacer "extensiones" para cada uno de los conectores, a excepción del hdmi, el cual se accede directamente.

Esta foto muestra ya el trabajo en el frente y tapa posterior casi terminado. Atrás a la izquierda el jack para la entrada de +5v que alimenta la RasPi como el Hub. En el centro de la parte posterior, la abertura para el plug hdmi y a la derecha el jack RJ-45 para la ethernet. En esa imagen aún no había agregado los orificios para los jack de audio y RCA de video compuesto.
Todos los agujeros fueron hechos solamente con un par de mechas y limas para darles la forma adecuada.

Lo que sí modifiqué un poquito fue el hub USB. Utilicé uno chinísimo (con DOC: Denominación de Origen Controlada) si se me permite la humorada. En él, desoldé los jacks USB. Los nuevos jacks del frente los soldé en una plaqueta universal y le hice extensiones con cable plano, que van hasta la plaquita del USB.
Otro de los USB va en la parte de atrás, como se ve en la imagen.

Sobre la base del gabinete pegué los separadores plásticos (con la Gotita, trademark by PoxyPol) donde se atornilla la placa de la RasPi.

En esta segunda imagen se pueden ver más de los componentes, ya montados. La RasPi, el hub chinísimo, con sus extensiones. En la de abajo, ya con todo conectado y funcionando.

La forma de alimentar la RasPi merece un comentario breve. Por qué sus diseñadores le habrán puesto un jack micro-usb cuando la mayoría de las SBC viene con un jack de dos conductores? Yo creo que para que forzando a los usuarios a usar un cargador de celular se evitara aplicar una tensión incorrecta. Supongo.
Pero lo cierto es que por el micro-USB no creo que pueda circular demasiada corriente (la RasPi modelo B requiere a la fuente unos 700mA). Por eso, encontrar un conector micro-usb para conectarle fue la parte más dificil del proyecto, porque no son muy populares. Queda por averiguar si es que la placa se puede alimentar por algún PIN del GPIO, ya que eso ayudaría.




Aquí se ve el aspecto exterior, al frente y posterior.

Work in progress

Así es como está el estado actual de este proyecto, que me dió algo más de diversión los fines de semana. Quedan cosas por hacer, como intentar darle algún acabado que le otorgue algo de eye-candiness. Eso no es sencillo, pero ya se verá.
Un tema que me preocupaba un poco era la temperatura del SoC de la RasPi, la pastilla que contiene la CPU y la GPU. La estoy usando sin overclocking, y sin disipadores. De momento todo va bien. Pero tiendo a pensar que si se quiere hacer overclocking u overvolting habrá que buscar alguna solución térmica, como abertura para que el aire circule o los indeseables ventiladores.


Continuar »