El SDK del IGEPv2

Continuando con el articulo que escribí hace ya un tiempo sobre el IGEPv2, voy a explicar los pasos necesarios para crear tu propio SDK para esta plataforma embedded.


El proyecto Yocto

Generar un SDK desde cero no es una tarea sencilla, en absoluto. Para hacer la tarea de forma sencilla, nos vamos a ayudar de la meta-distribución Yocto Poky distribuida por ISEE y personalizada para su plataforma IGEPv2.

Yocto Poky esta basada en la herramienta bitbake, herramienta que hace uso de unos ficheros de recipes (reglas) preparadas para hacer tareas complejas. Entre sus reglas, podemos encontrar una que nos permite generar el SDK para la plataforma IGEPv2. Veremos que el proceso para generar este SDK es muy sencillo (aunque costoso computacionalmente).


Dependencias previas

Vamos a realizar la compilación del SDK para el IGEPv2 usando un PC host con la distribución Ubuntu 12.04 LTS instalada. Es necesario instalar estos paquetes antes de empezar el proceso:

    $ sudo apt-get install diffstat
    $ sudo apt-get install texi2html
    $ sudo apt-get install texinfo
    $ sudo apt-get install gawk
    $ sudo apt-get install chrpath
    $ sudo apt-get install gnupg
    $ sudo apt-get install libcurl3
    $ sudo apt-get install libcurl3-gnutls
    $ sudo apt-get install python-pycurl


Si usáis otra distribución distinta, puede que falten, o puede que sobren paquetes.


Generación del SDK

El primer paso es clonar Poky del repositorio git de ISEE.

    $ git clone -b denzil git://git.isee.biz/pub/scm/poky.git
    Initialized empty Git repository in /mnt/data/gatchets/IGEPv2/poky/.git/
    remote: Counting objects: 62407, done.
    remote: Compressing objects: 100% (19827/19827), done.
    remote: Total 62407 (delta 41254), reused 61256 (delta 40311)
    Receiving objects: 100% (62407/62407), 38.81 MiB | 318 KiB/s, done.
    Resolving deltas: 100% (41254/41254), done.


El paso anterior debe haber generado dentro de tu directorio local un directorio llamado "poky".

Descargar el layer de ISEE del repositorio git:

    $ cd poky
    $ git clone -b denzil git://git.isee.biz/pub/scm/meta-isee.git

Configura el entorno de bitbake:

    $ source oe-init-build-env

Al hacer un source del fichero anterior, en realidad estas provocando  cambios en la variable de entorno PATH y estableciendo otras variables de entorno que usa la herramienta bitbake para hacer su trabajo. La primera vez que ejecutas este comando "source" se crea un directorio "build" con estos ficheros de configuración en su interior:

    $ find
    .
    ./conf
    ./conf/bblayers.conf
    ./conf/local.conf

A continuación modifica el contenido del fichero conf/bblayers.conf. Debería contener esta información (falta añadir el layer meta-isee)

    $ cat conf/bblayers.conf

    Code: Select all
    # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
    # changes incompatibly
    LCONF_VERSION = "4"

    BBFILES ?= ""
    BBLAYERS ?= " \
      /path/to/poky/meta \
      /path/to/poky/meta-yocto \
      /path/to/poky/meta-isee \
      "

Editar el fichero conf/local.conf (que ya debe existir, no deberías crearlo a mano) y cambia la variable MACHINE para que ponga esto:

    MACHINE ??= "igep00x0"

Ahora ya puedes lanzar el comando que genera el SDK:

    $ bitbake meta-toolchain-sdk

Y tener mucha paciencia [...] Este proceso tarda unas cuantas horas. En mi PC, un Intel Core i3, con 4GB de RAM, han sido casi 16 horas de compilación.

Cuando el proceso termine, el SDK queda listo en este path:

    poky/build/tmp/deploy/sdk/igep-sdk-yocto-toolchain-1.2.1-2.tar.bz2


Instalación del SDK

Una vez generado el SDK, hay que instalarlo en tu sistema host. Para hacerlo, sigue estos pasos:

    $ cd poky/build/tmp/deploy/sdk
    $ sudo -s
    $ tar xvfj igep-sdk-yocto-toolchain-1.2.1-1.tar.bz2 -C /

El comando anterior desplegará todo el SDK del IGEPv2 dentro del directorio:

    /opt/poky/1.2/

No cambies ese directorio, ya que ese path esta hardcoded dentro de los binarios del SDK, y si cambias a un path diferente, no te funcionará correctamente.


Uso del SDK

Para configurar el entorno para compilar binarios para esta plataforma, basta con ejecutar este script:

    $ . /opt/poky/1.2/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi

Fijate en el punto '.' antes del path, es necesario para que los cambios que se hacen en el entorno queden ahi cuando el script termine de ejecutarse.

Ahora ya tienes disponibles en tu path los compiladores cruzados para tu nueva plataforma ARM:

    $ arm-poky-linux-gnueabi-gcc --version
    arm-poky-linux-gnueabi-gcc (GCC) 4.6.4 20120303 (prerelease)
    Copyright (C) 2011 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ arm-poky-linux-gnueabi-g++ --version
    arm-poky-linux-gnueabi-g++ (GCC) 4.6.4 20120303 (prerelease)
    Copyright (C) 2011 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

A partir de este momento ya puedes usar el SDK del ARM de forma análoga a como usarías el SDK de tu PC host nativo.

Además de usar las herramientas cruzadas (cross-compilador, cross-linker, etc.) has de tener en cuenta que debes cambiar el SDK_PREFIX para que apunte al directorio raíz del SDK recién instalado. ¿Que significa esto? Pues que cuando compilas en tu PC host, el SDK_PREFIX siempre es este:

    SDK_PREFIX="/"

En realidad, ni siquiera se define, ya que tus ficheros de header estan en /usr/include y tus librerías en /usr/lib. Sin embargo, cuando usas un SDK cruzado, el SDK_PREFIX ya no es "/", debe cambiar para apuntar al nuevo directorio, en nuestro caso:

    SDK_PREFIX=/opt/poky/1.2.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/

Esto es así porque los headers de compilación para tu plataforma ARM no estan en /usr/include, sino que están en $SDK_PREFIX/usr/include. Y las librerías de linkado para tu plataforma ARM no estan en /usr/lib, sino que están en $SDK_PREFIX/usr/lib.

Teniendo esto en cuenta, compilar un proyecto para ARM es tan simple como hacerlo para la máquina nativa.


Trabajo pendiente

Veremos mas adelante como usar el SDK que acabamos de construir para compilar el binario del x-loader (MLO), la imagen del kernel de Linux (zImage), y un target filesystem con el que vamos a arrancar la placa.