Category Archives: GNU

Creación de una imagen Emdebian para tu FriendlyArm

0
Posted by javieralso on 22 Julio 2010 – 13:08
Filed under ARM, Debian, Embedded, GNU, mini2440
Tagged as , , ,

Introducción

Emdebian es una distribución Debian especialmente diseñada para dispositivos empotrados. Su principal característica radica en el poco espacio que ocupa la distribución.

Emdebian ofrece una Toolchain, un conjunto de herramientas de compilación cruzadas para crear paquetes para nuestra plataforma y repositorios con paquetes que ofrecen soporte a arquitecturas arm, ia64, m68k, mips, mipsel, powerpc y sparc. La instalación puede realizarse desde una máquina Debian con una arquitectura distinta a la arquitectura destino sin ningún tipo de problema utilizando debootstrap o, como se hará en ésta receta, utilizando multistrap, que permite crear un sistema nuevo utilizando varios repositorios y echando mano de apt y dpkg para solucionar posibles conflictos.

Qué necesitamos

Pues como he dicho anteriormente, utilizaremos multistrap, así que nos lo instalamos en nuestra máquina (ya sabeís, apt-get o aptitude bla, bla, bla…).

Además, supondremos que seguimos las recetas anteriores sobre cómo compilar Linux para mini2440 y sobre cómo configurar u-boot para arrancar el sistema desde una micro-sd.

Deberemos tener una tarjeta microSD con dos particiones, una para el núcleo y otra que dejaremos para el sistema (como se explicó en la receta sobre la compilación de Linux). Tendremos el árbol de directorios resultante de la compilación de Linux, pues lo necesitaremos para instalar los módulos del núcleo.

Creación de la imagen

Como se comentó anteriormente, utilizaremos multistrap para crear la imagen de emdebian. Para ejecutar multistrap antes deberemos crear un archivo de configuración en el que especificaremos los repositorios desde los que descargaremos los paquetes, la arquitectura destino y el directorio que se utilizará como destino para la instalación, entre otras cosas. El archivo que he utilizado yo es el siguiente:

  1. [General]
  2. arch=armel
  3. directory=multistrap
  4.  
  5. #cleanup=true
  6. # same as –no-auth option if set to true
  7. # keyring packages listed in each debootstrap will
  8. # still be installed.
  9. noauth=false
  10. # extract all downloaded archives (default is true)
  11. unpack=true
  12. # aptsources is a list of sections to be used for downloading packages
  13. # and lists and placed in the /etc/apt/sources.list.d/multistrap.sources.list
  14. # of the target. Order is not important
  15. aptsources=Emdebian
  16. # the order of sections is not important.
  17. # the debootstrap option determines which repository
  18. # is used to calculate the list of Priority: required packages.
  19. debootstrap=Debian Emdebian
  20.  
  21. [Emdebian]
  22. packages=ifupdown udev procps netbase vim-tiny module-init-tools wget openssh-server screen apmd
  23. source=http://www.emdebian.org/grip/
  24. keyring=emdebian-archive-keyring
  25. suite=squeeze main
  26.  
  27. [Debian]
  28. packages=
  29. source=http://ftp.uk.debian.org/debian
  30. keyring=debian-archive-keyring
  31. suite=squeeze main

La clave arch especifica la arquitectura destino de la distribución, en éste caso armel y la clave directory especifica el directorio destino en el que se desplegará la instalación. En nuestro caso, lo hará dentro del directorio multistrap, subdirectorio del directorio en el que se encuentra nuestro archivo de configuración.

Es importante que la clave cleanup esté comentada (o puesta a false). Ésto hará que la caché de apt no se limpie tras la instalación, pues necesitaremos los paquetes para reinstalarlos en el último paso desde la plataforma destino. El resto de opciones del archivo se pueden ver en la página sobre emdebian, así que no las comentaré aquí.

Guardamos el fichero con el nombre multistrap.conf (por darle algún nombre). Después, podemos instalar:

  1. javieralso@rigoberto:~/emdebian$ ls
  2. multistrap  multistrap.conf
  3. javieralso@rigoberto:~/emdebian$ sudo multistrap –no-auth -f multistrap.conf

Podemos ver que el directorio multistrap en el que quedará instalado emdebian y el archivo de configuración están bajo el mismo directorio. Tras invocar a multistrap podremos ver como se descargan los paquetes y se desempaquetan dentro del directorio multistrap.

Ahora tendremos un sistema muy básico que todavía no es funcional del todo. Tendremos que reinstalar todos los paquetes en el sistema destino, para lo cual deberemos poder logearnos. Como la distribución que tenemos es muy básica, no podremos hacerlo, puesto que /etc/passwd aún no existe, así que nos lo creamos nosotros:

  1. javieralso@rigoberto:~/emdebian$ cd multistrap
  2. javieralso@rigoberto:~/multistrap$ sudo su
  3. rigoberto:/home/javieralso/emdebian/multistrap# echo "root:Npge08pfz4wuk:0:0:root:/root:/bin/bash" > etc/passwd
  4. rigoberto:/home/javieralso/emdebian/multistrap# echo "root:Npge08pfz4wuk:0:" > etc/group
  5. rigoberto:/home/javieralso/emdebian/multistrap#

Como podemos ver, también hemos creado el archivo /etc/group. Recordad tener cuidado con no sobreescribir los archivos de VUESTRA máquina, no la vayais a liar….

Lo que hemos hecho ha sido asignar la contraseña password al usuario root utilizando el formato de contraseña salt/password, aunque para finalizar, aún debemos hacer mas cosas:

  1. rigoberto:/home/javieralso/emdebian/mutistrap# echo "proc /proc proc none 0 0" >>etc/fstab
  2. rigoberto:/home/javieralso/emdebian/multistrap# echo "mini2440" >etc/hostname
  3. rigoberto:/home/javieralso/emdebian/multistrap# mknod dev/console c 5 1
  4. rigoberto:/home/javieralso/emdebian/multistrap# mknod dev/ttySAC0 c 204 64

Después de ésto, empaquetamos el directorio.

  1. rigoberto:/home/javieralso/emdebian/multistrap# tar jcf ../emdebian-grip-071910-armel-debootstrap-squeeze.tar.bz2 .
  2. rigoberto:/home/javieralso/emdebian/multistrap#

Ahora, suponiendo que hemos montado la partición 2 de la tarjeta microSD (donde se supone que vamos a instalar el sistema) en el directorio /media/rootfs, podemos cargar ahí el sistema recién creado:

  1. rigoberto:/home/javieralso/emdebian/multistrap# cd ..
  2. rigoberto:/home/javieralso/emdebian# unp emdebian-grip-071910-armel-debootstrap-squeeze.tar.bz2 /media/rootfs/
  3. rigoberto:/home/javieralso/emdebian#

Instalamos los módulos del núcleo que compilamos en su momento, para eso, nos vamos al directorio mini2440 que creamos en su día y ejecutamos lo siguiente:

  1. javieralso@rigoberto:~/kernel/mini2440# sudo make INSTALL_MOD_PATH=/media/rootfs/  O=../kernel-bin/ modules_install
  2. …………………………………………………………………………………..
  3. …………………………………………………………………………………..
  4. Lots and lots of INSTALL messages
  5. …………………………………………………………………………………..
  6. …………………………………………………………………………………..

Desmontamos la tarjeta, la insertamos en nuestra MINI2440 y arrancamos (conectando el puerto serie de la tarjeta a nuestro PC y arrancando minicom).

Cuando el sistema termine de arrancar, veremos que se para porque no encuentra el archivo /etc/inittab:

  1. …………………………………………………………………………………..
  2. …………………………………………………………………………………..
  3. …………………………………………………………………………………..
  4. …………………………………………………………………………………..
  5. …………………………………………………………………………………..
  6. mmcblk0: mmc0:b368 MSD   1.85 GiB
  7.  mmcblk0: p1 p2
  8. s3c2410-rtc s3c2410-rtc: setting system clock to 2010-07-20 23:14:47 UTC (1279667687)
  9. usb 1-1: new full speed USB device using s3c2410-ohci and address 2
  10. usb 1-1: configuration #1 chosen from 1 choice
  11. kjournald starting.  Commit interval 5 seconds
  12. EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
  13. EXT3 FS on mmcblk0p2, internal journal
  14. EXT3-fs: recovery complete.
  15. EXT3-fs: mounted filesystem with writeback data mode.
  16. VFS: Mounted root (ext3 filesystem) on device 179:2.
  17. Freeing init memory: 136K
  18. INIT: version 2.88 booting
  19. INIT: No inittab file found
  20. Enter runlevel:

Introducimos ‘s’ (single user) y cuando nos pida contraseña introducimos: “password“. De ésta forma tendremos una Shell con permisos de root muy básica, pero con la que podremos terminar de instalar el sistema.

A continuación remontamos el sistema de archivos como sistema de lectura/escritura:

  1. root@(none):~# mount -n / -o remount,rw

y después montamos el sistema de archivos /proc:

  1. root@(none):~# mount -n /proc

Ahora debemos reinstalar todos los paquetes. Aunque los paquetes ya “están” en el disco, debemos “reinstalarlos” para que se genere la base de datos del sistema:

  1. root@(none):~# cd /var/cache/apt/archives
  2. root@(none):/var/cache/apt/archives# dpkg –force-all -i libc6* libstdc++* libncurses5* dpkg_*
  3. ………………………………………………………………………………
  4. ………………………………………………………………………………
  5. lots and lots of installation messages
  6. ………………………………………………………………………………
  7. ………………………………………………………………………………
  8. root@(none):/var/cache/apt/archives# dpkg –force-all -i apt*.deb
  9. ………………………………………………………………………………
  10. ………………………………………………………………………………
  11. lots and lots of installation messages
  12. ………………………………………………………………………………
  13. ………………………………………………………………………………

Una vez que tenemos instalado apt, reinstalamos todos los paquetes configurando la lista selections de dpkg:

  1. root@(none):/var/cache/apt/archives# ls *.deb | sed ‘s/\([^_]*\)_.*/\1 install/’ | dpkg –set-selections
  2. root@(none):/var/cache/apt/archives# apt-get dselect-upgrade
  3. ………………………………………………………………………………
  4. ………………………………………………………………………………
  5. lots and lots of installation messages
  6. ………………………………………………………………………………
  7. ………………………………………………………………………………

Aquí es muy probable que se produzcan errores durante la reinstalación. cuando ésto suceda se vuelve a ejecutar apt-get dselect-upgrade hasta que se termine. Para algunos paquetes es posible incluso que tengas que tocar algo a mano, como por ejemplo para que el paquete base-files pueda instalarse correctamente, que en mi caso me fue necesario eliminar el directorio /var/mail a mano.

En éste punto ya casi hemos terminado. Ahora solo falta activar la consola a través de puerto serie:

  1. root@(none):/var/cache/apt/archives# cd /
  2. root@(none):/# echo ttySAC0 >>etc/securetty
  3. root@(none):/# printf "T0:123:respawn:/sbin/getty 115200 ttySAC0\n" >>etc/inittab

¡Y ya está! Reinicia el sistema y ya tendrás una Debian flamante corriendo en tu MINI2440. ¡¡A disfrutarla!!

  1. …………………………………………………………………………………..
  2. …………………………………………………………………………………..
  3. …………………………………………………………………………………..
  4. …………………………………………………………………………………..
  5. …………………………………………………………………………………..
  6. Mounting local filesystems…done.
  7. Activating swapfile swap…done.
  8. Cleaning up temporary files….
  9. Configuring network interfaces…done.
  10. Cleaning up temporary files….
  11. Setting kernel variables …done.
  12. Running scripts in rcS.d/ took 20 seconds.
  13. INIT: Entering runlevel: 2
  14. Using makefile-style concurrent boot in runlevel 2.
  15. apmd[1110]: apmd 3.2.1 interfacing with apm driver 1.13 and APM BIOS 1.2
  16. Starting Advanced Power Management daemon….
  17. Running scripts in rc2.d/ took 2 seconds.
  18. Debian GNU/Linux squeeze/sid MINI2440 ttySAC0
  19. MINI2440 login: root
  20. Password:
  21. Last login: Wed Jul 21 01:14:00 CEST 2010 on ttySAC0
  22. Linux MINI2440 2.6.32-rc8 #1 Mon Dec 7 16:07:52 CET 2009 armv4tl
  23. The programs included with the Debian GNU/Linux system are free software;
  24. the exact distribution terms for each program are described in the
  25. individual files in /usr/share/doc/*/copyright.
  26. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  27. permitted by applicable law.
  28. root@MINI2440:~#

Y después…

Lo próximo es la creación de una imagen opie utilizando openembedded.

Referencias

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.

Errores en la post instalación de paquetes en entornos Debian

0
Posted by javieralso on 21 Diciembre 2009 – 1:40
Filed under GNU, General
Tagged as , ,

Muchas veces me ha pasado que instalando paquetes se han producido fallos debidos a que la “post instalación” no se ha efectuado correctamente. En estos casos, dpkg falla, dejando cualquier paquete que quede pendiente sin terminar. Ésto hace que además cualquier intento tanto de instalar como de desinstalar paquetes falle.

Una forma bastante tosca pero efectiva de solucionar ésto es acceder al script de postinstalación correspondiente y editarlo para que devuelva el valor esperado (generalmente 0). Como ya estoy harto de que siempre se me olvide donde están guardados esos archivos, aquí pongo la ruta.

  1. /var/lib/dpkg/info/paquetito.postinst

Éste archivo corresponde al script de postinstalación del paquete paquetito. Lo único que hay que hacer es que éste paquete devuelva el valor 0 y con ello la instalación podrá finalizar correctamente.

Instalando uBoot en una mini2440 (Friendlyarm)

2
Posted by javieralso on 24 Octubre 2009 – 14:08
Filed under ARM, Embedded, GNU, mini2440
Tagged as , , ,

Introducción

Como he comentado anteriormente, u-boot es un bootloader totalmente libre para dispositivos empotrados de bajo poder computacional. Entre sus múltiples posibilidades, están las de particionar la memoría flash del dispostivo en el que se encuentre corriendo, asignar nombre a dichas particiones, cargar imágenes en RAM desde distintas fuentes, volcarlas a flash, y un largo etcétera….
Aquí hablaré de las opciones que a mi juicio pueden ser mas socorridas para la instalación de un Sistema Operativo en un dispositivo empotrado, en mi caso, tomando como ejemplo la tarjeta de desarrollo mini2440 comentada anteriormente, aunque como es de suponer, las mismas operaciones pueden ser realizadas en distintas plataformas hardware.
Así pues vamos a lo divertido del asunto ¡¡Empezamos!!

Instalando

El proceso de instalación de u-boot consiste básicamente en cargar una imagen de u-boot en la RAM de nuestrá máquina, bien a través de su propio bootloader, bien a través de un JTAG. Una vez cargado en RAM, se lanza y se le dice que se (auto)guarde en la flash de nuestra tarjeta. En este caso y dependiendo de nuestro hardware, puede sobreescribir a su bootloader original o bien coexistir con él. En cualquier caso, deberás consultar el manual de tu tarjeta para comprobarlo.

Para el caso de la MINI2440, ésta viene con dos memorias Flash distintas: por un lado hay una flash NOR de 2MB en la que se encuentra almacenado el bootloader específico para los micros de Samsung (mirco de mi tarjeta de desarrollo): supervivi. Por otro lado, tenemos una memoria flash NAND de 128MB en la que se supone que irá nuestro sistema. En ésta memoria será en la que instalaremos u-boot, configurando posteriormente nuestra mini2440 para que arranque desde ahí (utilizando un conmutador que a tal efecto lleva instalado).

Para comenzar, necesitaremos descargarnos tanto el código fuente de u-boot como el software necesario para poder comunicarnos con supervivi y un compilador cruzado para ARM:

* u-boot:

  1. javieralso@rigoberto:~$ mkdir uboot; cd uboot
  2. javierlaso@rigoberto:~$ git clone git://repo.or.cz/u-boot-openmoko/mini2440.git
  3.  

* toolchain: Compiladores cruzados para ARM los hay muchos en esto de GNU. Yo, que seguí al dedillo todo lo que leí en montónes de blogs, usé el siguiente:

  1. javieralso@rigoberto:~$ wget http://www.codesourcery.com/sgpp/lite/arm/portal/package3696/public/arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
  2. javieralso@rigoberto:~$ unp  arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
  3. javieralso@rigoberto:~$ export PATH=$PATH:/home/rigoberto/arm-2008q3/bin

* Friendlyarm package: Se trata de un paquete con un uploader ya compilado para comunicarse con supervivi y de una imagen ya compilada de u-boot, que deberemos utilizar para cargar la imagen que compilemos nosotros. El por qué de usar dos imágenes de u-boot se explicará mas adelante.

  1. javieralso@rigoberto:~$ wget http://www.kernelconcepts.de/~fuchs/micro2440/friendlyarm2440-package.tar.bz2
  2. javieralso@rigoberto:~$ unp friendlyarm2440-package.tar.bz2

Una vez que lo tenemos todo descargado, empezaremos por compilar el bootloader, para ello no debemos olvidar añadir a nuestro PATH la ruta en la que se encuentran los binarios de la toolchain que usemos (como hicimos anteriormente). Una vez hecho esto, podemos pasar a compilar:

  1. javieralso@rigoberto:~$ cd uboot/mini2440
  2. javieralso@rigoberto:uboot/mini2440$ export CROSS_COMPILE=arm-none-linux-gnueabi-
  3. javieralso@rigoberto:uboot/mini2440$ make mini2440_config; make

Después de no mucho tiempo y si todo ha ido bien, deberemos tener un archivo llamado u-boot.bin en la carpeta donde hemos llevado a cabo la compilación. Esa es la imagen de u-boot que se almacenará en la flash de nuestra tarjeta, pero para poder llevar a cabo dicho proceso, necesitaremos otra versión de u-boot (sé que suena bastante raro, y de hecho lo es. Mas adelante explicaré el por qué de ello).

Bueno, llegados a este punto, cogemos nuestra mini2440, deslizamos el conmutador superior hacia la izquierda (para configurar el arranque desde la NOR), conectamos un módem nulo desde su puerto serie a un puerto serie de nuestra máquina y el device USB a un puerto USB libre. Tras ésto, arramcamos minicom y configuramos el puerto serie a 115200 Baudios, 8N1 y sin ningún tipo de contol de flujo.
Hecho ésto, solo queda encender nuestra tarjeta y comprobar que supervivi arranca:

  1. ##### FriendlyARM BIOS for 2440 #####
  2. [x] bon part 0 320k 2368k
  3. [v] Download vivi
  4. [k] Download linux kernel
  5. [y] Download root_yaffs image
  6. [c] Download root_cramfs image
  7. [a] Absolute User Application
  8. [n] Download Nboot
  9. [e] Download Eboot
  10. [i] Download WinCE NK.nb0
  11. [w] Download WinCE NK.bin
  12. [d] Download & Run
  13. [z] Download zImage into RAM
  14. [g] Boot linux from RAM
  15. [f] Format the nand flash
  16. [p] Partition for Linux
  17. [b] Boot the system
  18. [s] Set the boot parameters
  19. [t] Print the TOC struct of wince
  20. [u] Backup NAND Flash to HOST through USB(upload)
  21. [r] Restore NAND Flash from HOST through USB
  22. [q] Goto shell of vivi
  23. Enter your selection:

Seleccionamos la opción q para acceder a la shell de superivi y después le diremos que queremos cargar una imagen en la memoria y arrancar, pero para ello, antes deberemos saber cuando ocupa el bootloader que vamos a cargar (el que ya viene compilado), así que volvemos a la carpeta en la que lo descomprimimos y lo comprobamos:

  1. javieralso@rigoberto:friendlyarm2440-package$ ls -l
  2. …………………..
  3. …………………..
  4. -rwxr-xr-x   1 javieralso javieralso 239016 oct 24 11:38 u-boot.bin
  5. …………………..
  6. …………………..

Podemos ver que ocupa 239016 bytes. Guardamos este dato, nos será util para lo que comentamos anteriormente.

  1. Enter your selection:q
  2. Supervivi> load flash 0 239016 u
  3. USB host is connected. Waiting a download.

Con esto le hemos dicho a supervivi que queremos cargar 239016 bytes de datos (observad que es la misma cantidad de bytes que ocupa la imagen de u-boot) en la RAM de la tarjeta. Ahora supervivi se ha quedado esperando los datos, que deberemos envíarselos vía USB. Habiendo conectado el cable USB como se indicó antes ejecutamos el uploader:

  1. javieralso@rigoberto: friendlyarm2440-package$ sudo ./s3c2410_boot_usb u-boot.bin

que deberá ser llamado desde la carpeta friendlyarm2440-package y con sudo para poder tener acceso al puerto USB.

Si todo ha ido bien, supervivi debería mostar algo como esto:

  1. Now, Downloading [ADDRESS:30000000h,TOTAL:232706]
  2. RECEIVED FILE SIZE:  239016 (28KB/S, 8S)
  3. Downloaded file at 0×30000000, size = 232696 bytes
  4. Found block size = 0x0003c000
  5. Erasing…    … done
  6. Writing…    … done
  7. Written 239016 bytes
  8. Supervivi>

Ahora, arrancamos u-boot:

  1. Supervivi> go 0×30000000

y ya está, nuestra tarjeta arrancará u-boot:

  1. U-Boot 1.3.2-mini2440 (May 15 2009 – 21:24:49)
  2. I2C:   ready
  3. DRAM:  64 MB
  4. Flash:  2 MB
  5. NAND:  Bad block table not found for chip 0
  6. Bad block table not found for chip 0
  7. 64 MiB
  8. *** Warning – bad CRC or NAND, using default environment
  9. USB:   S3C2410 USB Deviced
  10. In:    serial
  11. Out:   serial
  12. Err:   serial
  13. MAC: 08:08:11:18:12:27
  14. Hit any key to stop autoboot:  0

Lo primero que ha hecho u-boot al arranchar ha sido darnos un mensaje de alerta indicando que el contenido de las variables de entorno no está fijado y de ahí el error CRC que se ve. Éstas variables de entorno son necesarias para que u-boot pueda configurarse al arrancar, pero antes de crearlas debemos de preparar la memoria NAND.

Para preparar la NAND, lo primero que haremos será borrar el listado de sectores defectuosos y volver a crearlo nosotros. Los sectores defectuosos son una lista, generalmente almacenada en fábrica, que indica qué sectores de la NAND son defectuosos. Lo normal es que haya alguno y con el tiempo y el uso se irán incrementando.

  1. MINI2440 # nand scrub
  2. NAND scrub: device 0 whole chip
  3. Warning: scrub option will erase all factory set bad blocks!
  4.          There is no reliable way to recover them.
  5.          Use this command only for testing purposes if you
  6.          are sure of what you are doing!
  7. Really scrub this NAND flash? <y/N>
  8. Erasing at 0x33d4000 —  81% complete.
  9. NAND 64MiB 3,3V 8-bit: MTD Erase failure: -5
  10. Erasing at 0x3ffc000 — 100% complete.
  11. Bad block table not found for chip 0
  12. Bad block table not found for chip 0
  13. OK
  14. MINI2440 #

Con el comando anterior borramos la lista de sectores defectuosos antes mencionada. Después de haber hecho la limpieza, creamos nuestra propia tabla (también conocida como BBT):

  1. MINI2440 # nand createbbt
  2. Create BBT and erase everything ? <y/N>
  3. Skipping bad block at  0×03410000                                            
  4. Skipping bad block at  0x03ff0000                                            
  5. Skipping bad block at  0x03ff4000                                            
  6. Skipping bad block at  0x03ff8000                                            
  7. Skipping bad block at  0x03ffc000                                            
  8. Creating BBT. Please wait …Bad block table not found for chip 0
  9. Bad block table not found for chip 0
  10. Bad block table written to 0x03ffc000, version 0×01
  11. Bad block table written to 0x03ff8000, version 0×01

Este proceso es relativamente lento, por lo que habrá que esperar que esperar (3-4 minutillos), así que mientras tanto, busca una tarjeta SD y copia el binario u-boot.bin QUE COMPILASTE en dicha tarjeta. La cargaremos desde ahí.

Una vez que tenemos nuestra SD con el binario cargado y que ya se ha generado la nueva BBT, introducimos la tarjeta en el lector de la mini2440 y le decimos a u-boot que la detecte:

  1. MINI2440 # mmcinit
  2. trying to detect SD Card…
  3. Manufacturer:       0×30, OEM "SD"
  4. Product name:       "SU02G", revision 8.0
  5. Serial number:      3489032
  6. Manufacturing date: 9/2010
  7. CRC:                0×27, b0 = 1
  8. READ_BL_LEN=15, C_SIZE_MULT=7, C_SIZE=365
  9. size = 1642070016

Con la tarjeta ya detectada, cargamos u-boot.bin en la RAM:

  1. MINI2440 # fatload mmc 0:1 0×32000000 u-boot.bin
  2.  
  3. 233412 bytes read

¿Qué ha pasado? pues que le hemos dicho a u-boot que cargue el archivo binario u-boot.bin desde un sistema de archivos FAT (fatload), ubicado en la SD (mmc), dispositivo 1, primera partición (0:1), a partir de la dirección de memoria 0×32000000.

Una vez que tenemos el archivo en RAM, lo volcamos a la NAND:

  1. MINI2440 # nand write.e 0×32000000 0×0 0x38fc4
  2. NAND write: device 0 offset 0×0, size 0x38fc4
  3. Writing data at 0x38c00 — 100% complete.
  4.  233412 bytes written: OK

Bueno, en este caso, hemos escrito 0x38fc4 bytes (233412, para que nos entendamos), al comienzo de la NAND. El numerajo hexadecimal, como hemos visto corresponde al peso de u-boot.bin pero ésta vez del que hemos compilado NOSOTROS, no del que cargamos en RAM al principio. Importante no confundir ésto. Un apunte importante es que en ésta parte del proceso, la longitud deberá darse en hexadecimal, no en decimal, ya que ello puede dar lugar a errores.

Por lo que he leído por ahí, el modificador .e del comando write se utiliza para generar códigos de correción de errores y evitar así lo posibles bloques defectuosos que pueda haber en la NAND (recordad el comando createbbt de antes).

Una vez hecho esto, podemos reiniciar tranquilos nuestra mini2440: u-boot la hará arrancar. Aunque no hará mucho mas ya que la NAND está completamente borrada y no hay sistema.

Para finalizar debemos indicar a u-boot donde está la partición dedicada a las variables de entorno. Para ello primero debemos de conocer la tabla de particiones de nuestra memoria NAND, que deberá estar formateada de fábrica (si no es así puede hacerse desde el menú de supervivi). El comando mtdparts nos proporcionará dicha información:

  1. MINI2440 # mtdparts
  2.  
  3. device nand0 <mini2440-nand>, # parts = 4
  4.  #: name                        size            offset          mask_flags
  5.  0: u-boot              0×00040000      0×00000000      0
  6.  1: env                 0×00020000      0×00040000      0
  7.  2: kernel              0×00500000      0×00060000      0
  8.  3: root                0x07aa0000      0×00560000      0
  9.  
  10. active partition: nand0,0 – (u-boot) 0×00040000 @ 0×00000000
  11.  
  12. defaults:
  13. mtdids  : nand0=mini2440-nand
  14. mtdparts: <NULL>

Podemos ver que tenemos cuatro particiones cuyos nombres son bastante descriptivos. La partición 1, env será la utilizada para las variables de entorno de u-boot, así que con dynenv lo configuramos:

  1. MINI2440 # dynenv set 40000
  2. device 0 offset 0×40000, size 0x7fc0000
  3. 45 4e 56 30 – 00 00 04 00

El comando introducido ha configurado la ubicación de las variables de entorno a partir de la dirección 0×40000, que como se puede ver en la tabla de particiones mostrada anteriormente, es la dirección offset (de comienzo) de la partición asignada a tal efecto.

Una vez configurada la ubicación de las variables de entorno, almacenamos la configuración con el comando saveenv:

  1. MINI2440 # saveenv
  2. Saving Environment to NAND…
  3. Erasing Nand…Writing to Nand… done

Y listo, ya tenemos u-boot instalado.

Para finalizar os contaré por qué antes utilicé dos versiones distintas de uboot. El motivo es que para instalar uboot, primero debe residir en la RAM y poderse ejecutar desde ahí, ya que hay que hacer una limpieza de la NAND antes de llevar a cabo la instalación propiamente dicha. Lo que observé entonces fue que las versiones de uboot que conseguían arrancar desde la RAM, no eran capaces de hacerlo luego una vez que se instalaban en NAND (en efecto, según los manuales que leí, una vez creada la BBT, se escribía el contenido de la RAM a la NAND, ya que allí es donde está uboot) y viceversa, las imágenes que si que eran capaces de arrancar desde la NAND no lo podían hacer desde la RAM. No sé si esto es por algún bug en uboot (que deberían ser entonces bugs distintos en cada una de las versiones) o porque yo hice algo mal (repetí montones de veces lo que vi en tutos, blogs y demás paso por paso). El caso es que después de varios intentos sin mucho éxito, decidí hacerlo tal y como lo he explicado aquí.

En el futuro….

En próximas recetas, explicaré qué comandos básicos utilizar en u-boot para cargar imágenes en RAM o NAND, configurar el arranque automático desde distintas fuentes, particionar la NAND, configurar opciones de arranque para el S.O. que tengamos y alguna cosilla mas. Evito poner esa información aquí para no sobrecargar demasíado esta receta, que se supone que tienen que ser breves y concisas.

Referencias

Muchas y muy variadas, aunque las mas importantes son éstas.

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.

Configuración de módem Huawei en GNU/Linux

0
Posted by javieralso on 22 Octubre 2009 – 11:38
Filed under GNU, Redes
Tagged as ,

Introducción

Si tienes una línea móvil de datos y un módem usb, tal vez te apetezca poder utilizarlo en tu GNU/Linux. Actualmente, los modems Huawei son los mas utilizados para éste tipo de propósitos. Aquí explico lo que hay que hacer para poder dar soporte al modelo Huawei E160, un módem que por lo que he podido probar, funciona pero que muy bien bajo GNU/Linux

Empezando

¿Cómo saber si tu modem es el soportado? (bueno, en principio cualquier módem Huawei debería funcionar sin problemas). Sencillo, después de pinchar el módem en tu puerto USB y tras ejecutar lsusb, lo verás:

  1. javieralso@rigoberto:~$ Bus 001 Device 008: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem

Además, la salida de dmesg deberá mostrar algo como ésto:

  1. javieralso@rigoberto:~$ dmesg
  2. ………….
  3. [ 4180.956314] usb 1-4.3: new high speed USB device using ehci_hcd and address 7
  4. [ 4181.067257] usb 1-4.3: New USB device found, idVendor=12d1, idProduct=1003
  5. [ 4181.067260] usb 1-4.3: New USB device strings: Mfr=2, Product=1, SerialNumber=0
  6. [ 4181.067262] usb 1-4.3: Product: HUAWEI Mobile
  7. [ 4181.067264] usb 1-4.3: Manufacturer: HUAWEI Technology
  8. [ 4181.067376] usb 1-4.3: configuration #1 chosen from 1 choice
  9. [ 4181.072393] usb-storage: probe of 1-4.3:1.0 failed with error -1
  10. [ 4181.179711] usb 1-4.3: USB disconnect, address 7

Este tipo de módems, además de su función principal (la de módem), también pueden utilizarse como lector de tarjetas microSD. El problema aquí, es que por lo que he visto, necesitan un driver muy específico para esto último y por eso, bajo GNU/Linux no lo he podido hacer funcionar. De todas formas, lectores de tarjetas microSD los hay a patadas, así que que no nos hace falta sobrecargar a nuestro pobre modem.
Lo que si que sucede, es que una vez que se conecta el módem al puerto USB, la configuración que se activa por defecto parece ser la del lector microSD, así que tendremos que cambiar esto para poder acceder al pincho como módem que es lo que nos interesa. Empecemos pues.

usb-modeswitch

usb-modeswitch permite realizar exactamente lo que comentaba antes, es decir, cambiar la configuración seleccionada del módem para que pueda actuar como tal. Parece ser que es paquete Debian, así que si utilizas éste Sistema Operativo, ya sabes:

  1. javieralso@rigoberto:~$ apt-get install usb-modeswitch

Además de usb-modeswitch, también necesitaremos ivman para poder detectar cuando se conecta el módem a nuestro equipo y autoconfigurarlo llamando a usb-modeswitch…

  1. javieralso@rigoberto:~$ apt-get install ivman

Configurandolo todo

Una vez que ya lo tienes todo instalado, solo falta escribir un poco de configuración para que el módem eche a andar. Una de las primeras cosas que debemos hacer, es configurar ivman para que arranque automáticamente al iniciar sesión. Éso se puede hacer fácilmente desde Sistema–>Preferencias–>Aplicaciones al inicio (Supongo que utilizarás gnome).
Después de ésto, abrimos el archivo $HOME/.ivman/IvmConfigActions.xml. Éste archivo dice a ivman qué tiene que hacer según qué eventos detectos detecte en la capa HAL. En nuestro caso, con añadir lo siguiente, debería ser mas que suficiente:

  1. <!– Change Huawei E160 Mode –>
  2.     <ivm:Match name="hal.storage.physical_device" value="/org/freedesktop/Hal/devices/usb_device_12d1_1003_noserial_if0">
  3.             <ivm:Option name="exec" value="xterm -e $HOME/.e160.sh" />
  4.     </ivm:Match>
  5. </ivm:ActionsConfig>
  6.  

Con ésto, lo que se le dice a ivman es que cuando detecte el módem insertado (se puede ver en la tercera línea como en el valor para la clave name se compone el nombre con el vendorID = 0x12d1 y el productID = 0×1003, que se obtuvieron al ejecutar lsusb) ejecute el script $HOME/.e160.sh. En éste script están los comando para activar usb-modeswitch y hacer que configure correctamente el módem.

Dicho script tiene el siguiente contenido:

  1. #!/bin/bash
  2.  
  3. if [ -z "`/bin/ls /dev/ttyUSB0`" ]; then
  4.         if [ "`/usr/sbin/lsusb | grep 12d1 | cut -d : -f3 | cut -b -4`" = "1003" ]; then
  5. #                /usr/bin/usb_modeswitch -v 12d1 -p 1003 -d 1
  6.                 /usr/bin/usb_modeswitch -v 12d1 -p 1003 -H 1
  7.         fi
  8. fi
  9.  

No olvides darle permisos de ejecución después de editarlo.

En principio con ésto, el módem quedaría perfectamente configurado. Sería aconsejable reiniciar gdm, pues ivman crea su propio usuario y puede que no funcione correctamente hasta que no salgas y vuelvas a entrar al sistema (no hace falta reiniciar, que ésto es GNU/Linux :-P )

Si todo ha ido bien, cuando insertes el módem, dmesg te debería devolver algo como ésto:

  1. javieralso@rigoberto:~$ dmesg
  2. …………..
  3. [16197.508056] usb 2-6: new high speed USB device using ehci_hcd and address 12
  4. [16197.655583] usb 2-6: New USB device found, idVendor=12d1, idProduct=1003
  5. [16197.655590] usb 2-6: New USB device strings: Mfr=2, Product=1, SerialNumber=0
  6. [16197.655596] usb 2-6: Product: HUAWEI Mobile
  7. [16197.655600] usb 2-6: Manufacturer: HUAWEI Technology
  8. [16197.655756] usb 2-6: configuration #1 chosen from 1 choice
  9. [16197.742661] Initializing USB Mass Storage driver…
  10. [16197.743679] usb-storage: probe of 2-6:1.0 failed with error -1
  11. [16197.743727] usbcore: registered new interface driver usb-storage
  12. [16197.743732] USB Mass Storage support registered.
  13. [16197.744153] usb 2-6: USB disconnect, address 12
  14. [16205.112108] usb 2-6: new high speed USB device using ehci_hcd and address 13
  15. [16205.255571] usb 2-6: New USB device found, idVendor=12d1, idProduct=1003
  16. [16205.255578] usb 2-6: New USB device strings: Mfr=2, Product=1, SerialNumber=0
  17. [16205.255584] usb 2-6: Product: HUAWEI Mobile
  18. [16205.255588] usb 2-6: Manufacturer: HUAWEI Technology
  19. [16205.255737] usb 2-6: configuration #1 chosen from 1 choice
  20. [16205.262311] usb-storage: probe of 2-6:1.2 failed with error -1
  21. [16205.263306] usb-storage: probe of 2-6:1.3 failed with error -1
  22. [16205.343381] usbcore: registered new interface driver usbserial
  23. [16205.343408] USB Serial support registered for generic
  24. [16205.343497] usbcore: registered new interface driver usbserial_generic
  25. [16205.343501] usbserial: USB Serial Driver core
  26. [16205.354928] USB Serial support registered for GSM modem (1-port)
  27. [16205.355014] option 2-6:1.0: GSM modem (1-port) converter detected
  28. [16205.355174] usb 2-6: GSM modem (1-port) converter now attached to ttyUSB0
  29. [16205.355192] option 2-6:1.1: GSM modem (1-port) converter detected
  30. [16205.355278] usb 2-6: GSM modem (1-port) converter now attached to ttyUSB1
  31. [16205.355311] usbcore: registered new interface driver option
  32. [16205.355315] option: v0.7.2:USB Driver for GSM modems

Aquí se puede ver que el módem se detecta, se activa el soporte para almacenamiento masivo y después se cambia al modo módem.

Conectando a Internet

Bueno, pues ahora ya solo queda que te conectes a internet utilizando la compañia que mas te guste. Yo personalmente y llegados a éste punto, me leería un par de recetas pelín antiguas que explican como configurar las opciones de acceso a un operador concreto (en realidad es Simyo) utilizando wvidial o también gnome-ppp.

Ahí se pueden ver las opciones de configuración para el operador dado. Si utilizas otro operador, el número de marcado y demás serán distintos, así que tendrás que ponerte en contacto con ellos para que te lo faciliten. Coser y cantar ;-)

Referencias

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.

Programador para ChipCom CC2430 y sucedáneos bajo GNU/Linux

0
Posted by javieralso on 3 Junio 2009 – 8:54
Filed under Electrónica, Embedded, GNU, Zigbee
Tagged as

CC2430/CC2510/CC1110 – Flasher – Modula d.o.o..

GLib IO Channels con C

0
Posted by javieralso on 1 Mayo 2009 – 14:08
Filed under GNU, Programación, tinyOS
Tagged as , ,

Introducción

Un patrón reactor (o también conocido como Distpatcher), es un patrón de programación utilizado cuando queremos atender varios eventos que pueden suceder de forma asíncrona y en ocasiones simultáneamente, pero queremos que ésos eventos sean atendidos sínconamente y, a ser posible, ordenadamente según el orden en que llegaron los eventos.
Posibles aplicaciones de éste patrón las podemos ver, por ejemplo, en cualquier servidor que queda a la escucha de un socket (de Internet o de cualquier otro tipo, evidentemente) y los va atendiendo según se vayan produciendo conexiones entrantes.
También podemos tener una aplicación en la que si no se produce ninguna entrada durante un tiempo determinado, la aplicación cierre, y en caso contrario, ejecute distintas operaciones según la fuente de entrada.
En éste último caso, podríamos hacer uso de la llamada al sistema select(), pero aquí explicaré como implementar dicho patrón utilizando GLib.

Patrón reactor en C.

El código de ejemplo para ésta receta es el que se puede ver a continuación:

  1. #include <stdio.h>
  2. #include <glib.h>
  3.  
  4. gboolean handler1(gpointer data) {
  5.   printf ("Manejador 1\n");
  6.   return TRUE;
  7. }
  8.  
  9. gboolean handler2(gpointer data) {
  10.   printf ("Manejador 2\n");
  11.   return TRUE;
  12. }
  13.  
  14. gboolean handler3(GIOChannel *source, GIOCondition condition, gpointer data) {
  15.   int fd;
  16.   char buff[100];
  17.  
  18.   for (fd = 0; fd < 100; fd++) {
  19.     buff[fd] = 0;
  20.   }
  21.  
  22.   printf ("Manejador 3\n");
  23.   fd = g_io_channel_unix_get_fd (source);
  24.   read(fd, buff, 100);
  25.   printf ("Buffer: %s", buff);
  26.   return TRUE;
  27. }
  28.  
  29. int main (void) {
  30.   gpointer data;
  31.  
  32.   g_timeout_add(1000, handler1, data);
  33.   g_timeout_add(500, handler2, data);
  34.  
  35.   g_io_add_watch(g_io_channel_unix_new(0), G_IO_IN, handler3, NULL);
  36.   g_main_loop_run(g_main_loop_new(NULL, FALSE));
  37.   return 0;
  38. }

El código que se muestra es bastante simple y fácil de entender. Al principio, después de las inclusiones de las cabeceras necesarias, se declaran tres funciones que consisten en los manejadores de los eventos capturados. Los dos primeros son exactamente iguales y lo único que hacen es escribir un mensaje por pantalla. El tercer manejador se llama cuando se introducen datos por teclado. Lo único que hace es inicializar un buffer en el que después copiaremos los datos introducidos y finalmente los imprimiremos. Podemos ver que éstas tres funciones devuelven TRUE, mas adelante se verá el porqué.

La “chicha” del asunto está en la función main, que es la que se encarga de asignar los manejadores anteriores a cada una de las señales y de inicializar el bucle de eventos.
Las llamadas a g_timeout_add asignan los dos primeros manejadores a un evento de tiempo, que se generará, respectivamente, cada segundo y medio segundo. Por su parte, la llamada a g_io_channel_unix_new asigna el tercer manejador a los eventos de escritura generados a través de la entrada estándar (el teclado).
Finalmente, la penúltima línea se encarga de poner en funcionamiento el bucle principal, creado por la función que se llama como primer parámetro. En ese momento, el programa se queda “congelado” ahí y lo único que hace es esperar a que se produzcan los eventos programados (los dos de temporización y la entrada por el teclado).
Antes comenté que los manejadores siempre devolvian TRUE. Ésto se debe a que si devolviesen FALSE, no volverían a ser llamados. Así conseguimos que los manejadores vuelvan a ser ejecutados cuando se producen de nuevo los eventos.

Referencias

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.

udev: Configurando el acceso al USB sin ser root

0
Posted by javieralso on 1 Mayo 2009 – 13:04
Filed under GNU, General
Tagged as

Introducción

A veces sucede que quieres utilizar un dispositivo USB un poco “exótico” y resulta que no puedes utilizarlo sin ser root. Un ejemplo de ello puede ser dfu-programmer o pk2, que son aplicaciones no muy estándard y por lo tanto no se les ha dado el soporte necesario, haciendo que haya que invocarlas como root si queremos utilizarlas.

La solución para ésto pasa por crear unas reglas para udev que permitan que éstas aplicaciones accedan al puerto USB de nuestro PC en modo normal.

Un ejemplo: dfu-programmer

Ilustraré el proceso con una aplicación de ejemplo: dfu-programmer. Se trata de un cliente para el bootloader USB instalado en los micros con soporte para dicho interfaz de Atmel.
Para añadir las reglas, abrimos (mas bien creamos) el archivo que contedrá dichas reglas:

  1. yo@miMaquina:~$ sudo emacs /etc/udev/rules.d/99-dfu-programmer.rules

En este archivo, deberemos escribir algo tal que así:

  1. SUBSYSTEM=="usb", ACTION=="add", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2ffb", MODE="660", GROUP="plugdev", SYMLINK+="at90usb-%k"
  2. BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2ffb", MODE="660", GROUP="plugdev"

Básicamente lo que se hace es indicar a udev que dfu-programmer usa el sistema USB, dando información detallada acerca del vendorID y el productID del dispositivo que se va a conectar al puerto. También indica con qué permisos se debe acceder al puerto y especifica el grupo cuyos permisos hereda la aplicación.

Referencias

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.