Yoctoproject meta-fsl-arm and imx53 quick start board

Yoctoproject is a solid framework for creating Linux distributions for embedded devices, and its layering mechanism makes it easy to add Linux OS to new target devices; With highly customization for a particular device it can include custom start-up scripts, software packages built with a high degree of optimization for a particular architecture and different user graphical interfaces from full Gnome desktop to a simple a serial console.

YP has 2 basic layers, board support packages layer and core layer; In the BSP layer is where we include all the custom software and configuration tweaks for a particular platform; The core layer provides the common software stack to provide from a simple command line interface to Sato desktop interface (Matchbox based and Gnome mobile stack). A third layer could be added to provide additional user interfaces such as LXDE, XFCE, Active plasma and more; YP is quite flexible.

One of the problems with Freescale i.MX based platforms is the lack of openness, getting the BSP provided by FSL requires to download a large tarball which bundles the kernel, boot loader, user space applications and Ltib an ancient build system which generates a file system so 2004, literary the software stack is around those years probably older. And that’s why I started working on YP BSP support for i.MX5 targets, and now the project has it’s on life with active members helping on getting the best support possible.

Freescale iMX53 quick start board is an Arm cortex-a8 low cost development board, with interesting peripheral interfaces like Sata II, hdmi and GPU based on AMD Z160. And YP BSP layer has a decent support for it, at github Freescale site there are instructions on how to get started.

But with newest i.MX6 processor a Wandboard should be more appealing.

Advertisements

Omap3 evm

I just discover an Omap3 Evaluation module at my school laboratory and there’s some students that are going to start developing an GPS application; As far as I now they are kind of lost about developing Linux applications so I suggest them to look at the different SDK available like OpenEmbedded, Poky, Maemo SDK, Android; and to read about developing applications for Linux;

Tomorrow I’m going to start asking them about which SDK they want to use and in which programming language they prefer to use so I can give some hints and help to start in the right direction.

[root@OMAP3EVM /]# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 549.91
Features        : swp half thumb fastmult vfp edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0xc08
CPU revision    : 2
Cache type      : write-through
Cache clean     : not required
Cache lockdown  : not supported
Cache format    : Unified
Cache size              : 768
Cache assoc             : 1
Cache line length       : 8
Cache sets              : 64

Hardware        : OMAP3EVM Board
Revision        : 34301335
Serial          : 0000000000000000

Scratchbox + Maemo SDK 4.1.1 on Fedora 9

My everyday working machine is based on Fedora 9 x86_64. Since Scratchbox is officially supported only by i386 archs I have been looking for an optimal solution to get it working inside of my box.

The most clean solution is to fake an i386 architecture by using setarch command, this way the checking prerequisites are satisfied and you able to install scratchbox by following the usual procedure, with some workarounds.

Scratchbox know limitations:

Qemu “mmap_min_addr” value grather than 4096

Edit /etc/sysctl.conf and add:
vm.mmap_min_addr = 4096

Scratchbox doesn’t work when VDSO support is enabled in the host’s kernel.

To disable VDSO support in x86_64 kernels you need to add the vdso32=0 options
in your kenel boot line

Edit /boot/grub/menu.lst and add vdso32=0 my kernel boot looks like:

kernel /vmlinuz-2.6.26.6-79.fc9.x86_64 ro root=/dev/VolGroup00/LogVol00 rhgb quiet vdso32=0

Reboot your machine so VDSO can be disabled.

Installing Scratchbox:

Get the installer script:
wget http://repository.maemo.org/stable/4.1.1/maemo-scratchbox-install_4.1.1.sh

Give executable permitions to the script:
chmod +x maemo-scratchbox-install_4.1.1.sh

Disable Selinux:
echo 0 > /selinux/enforce

Other wise the installer script will complain

Fake a i386 arch:

sudo setarch i386

Run installer script:

sudo ./maemo-scratchbox-install_4.1.1.sh -s <install-path> -u <your-username>

This will take a while, when it finish you will see a massage like this:

Installation was successful!
—————————-

Installing Maemo SDK:

Download SDK installer script

wget http://repository.maemo.org/stable/4.1.1/maemo-sdk-install_4.1.1.sh

Give executable permitions to the script:
chmod +x maemo-sdk-install_4.1.1.sh

Fake i386 arch:

setarch i386

Satrt sbox service:

sudo <sb-install-path>/sbin/sbox_ctl start

Run the sdk install script
sh ./maemo-sdk-install_4.1.1.sh -y -s -d <sb-install-path>

Testing scratchbox and the sdk:

Install Xephyr server to forward sb xorg-X11

sudo yum install xorg-x11-server-Xephyr

Start Xephyr server:

Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac -extension Composite

Start sbox and login

sudo /opt/scratchbox/sbin/sbox_ctl start

/opt/scratchbox/login

Create a file named hello-maemo.c and add the following lines:

/*********/

#include <hildon/hildon-program.h>
#include <gtk/gtkmain.h>
#include <gtk/gtkbutton.h>

int main(int argc, char *argv[])
{
/* Create needed variables */
HildonProgram *program;
HildonWindow *window;
GtkWidget *button;

/* Initialize the GTK. */
gtk_init(&argc, &argv);

/* Create the hildon program and setup the title */
program = HILDON_PROGRAM(hildon_program_get_instance());
g_set_application_name(“Hello maemo!”);

/* Create HildonWindow and set it to HildonProgram */
window = HILDON_WINDOW(hildon_window_new());
hildon_program_add_window(program, window);

/* Create button and add it to main view */
button = gtk_button_new_with_label(“Hello!”);
gtk_container_add(GTK_CONTAINER(window), button);

/* Connect signal to X in the upper corner */
g_signal_connect(G_OBJECT(window), “delete_event”,
G_CALLBACK(gtk_main_quit), NULL);

/* Begin the main application */
gtk_widget_show_all(GTK_WIDGET(window));
gtk_main();

/* Exit */
return 0;
}

/*********/

Compile the hello-maemo example:

gcc -o hello-maemo hello-maemo.c `pkg-config –cflags gtk+-2.0 hildon-1` -ansi -Wall `pkg-config –libs gtk+-2.0 hildon-1`

Set the DISPLAY variable to poit to the Xephyr server

export DISPLAY=:2

Start the maemo scratchbox enviroment test script:

af-sb-init.sh start

Run the hello_maemo application:

run-standalone.sh ./hello_maemo

hello_maemo

References:

http://www.progbox.co.uk/wordpress/?p=453

http://znark.com/blog/2008/09/21/maemo-sdk-on-fedora-9

Poky Anjuta plug-in

Poky provides an plug-in for developing using Anjuta IDE, follow the next steps form building the plug-in:

Checkout the latest version

svn co http://svn.o-hand.com/repos/anjuta-poky/trunk anjuta-plugin-sdk
cd anjuta-poky-plugin-sdk
sudo ./autogen.sh
sudo make
sudo make install

Listo, now the next step is to configure the plug-in to start development with Anjuta,

In Anjuta go to Edit->Preferences

Enable the plug-in:

Anjuta-Poky Enable

Configure the toolchain path:
/usr/local/poky/eabi-glibc/arm/

Anjuta-Poky preferences

At the moment we will leave the Target options as shown in further post I will deal with this.

Close the preferences dialog; Create a New Project
File->New->Project
Select an C GTK+ type.

Run Autogenerate…
Build->Run Autogenerate…

You will see messages like:

checking for arm-poky-linux-gnueabi-strip… arm-poky-linux-gnueabi-strip
checking whether to enable maintainer-specific portions of Makefiles… yes
checking for style of include used by make… GNU
checking for arm-poky-linux-gnueabi-gcc… arm-poky-linux-gnueabi-gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… yes

If not then you are not setting correctly the toolchain root path or you misspell the toolchain prefix.

Now Build->Build Project

That would place a binary your src directory.

On my next post I will go through procedure of running the previous example on Quemu as target platform, while you can start designing and coding : )

More info at anjuta-poky-sdk-plugin

Building Poky SDK

There are several alternatives for cross development enviroments and Poky
is one of them; Poky supports a wide range of ARM architectures and 0x86,
it also provides support for Qemu system emulation.

The main feauture of poky is the inclusion of Sato which is a combination of
X11/Gtk+/Matchbox, this is the main difference with other sdk’s like Maemo
which use Hildon as GUI.

The sdk includes the toolchains, development headers and libraries for cross
compiling applications.

Building poky sdk is preatty simple

Checkout the latest version of Poky:

svn co http://svn.o-hand.com/repos/oprofileui/trunk/

cd poky

source poky-init-build-env

bitbake meta-toolchain-sdk

You may find this error:

ERROR:  Poky’s config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf). Following is the list of potential problems
/ advisories:

Using dash as /bin/sh causes various subtle build problems, please use
bash instead.

This is a long time bug in Debian/Ubuntu systems bug-61463 simple change the
/bin/sh symbolic link to point to bash istead of dash; See the bug report for
more information

sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

Re-run bitbake to start the SDK build.

Building the SDK will take a couple of hours, get a coffe and do something else.

By the way is possible that during the build process you end with some Errors
on building an specific package for example jpeg_6b the most common error is
that the src package can’t be found our the repository is down to solve this
edit the bitbake recipe for building this package.

vim meta/packages/jpeg/jpeg_6b.bb

….
SRC_URI = “http://www.ijg.org/files/jpegsrc.v${PV}.tar.gz \
….

And make sure that the package is available in the SRC_URI as declared if not
make the propper changes.

Once the SDK build ends a tarball will be place on

[poky root path]/build/tmp/deploy/sdk/

poky-eabi-glibc-x86_64-arm-toolchain-sdk-3.2+snapshot-20080511-extras.tar.bz2
poky-eabi-glibc-x86_64-arm-toolchain-sdk-3.2+snapshot-20080511.tar.bz2

Extract them on your root file system [/]

sudo tar xf poky-eabi-glibc-x86_64-*-20080511-extras.tar.bz2 -C /
sudo tar xf poky-eabi-glibc-x86_64-*-20080511.tar.bz2 -C /

that would place the SDK under

/usr/local/poky/

More information on poky official site.

Target platform

Linux is highly supported on different architectures like ARM, MIPS, x86, m68k. When some refers to a target platform is combination of an architecture (CPU) and a board that holds that CPU. Selecting the right platform depends on the application requirements or your actual needs.

If you are in the case as me (learning purposes) you can choose any know handled device that supports Linux like N800 Nokia tablet PC, Ipod player or if you can’t afford any of this gadgets you can use Qemu for target virtualization.

My choice is Qemu targeting an ARM achitecture.