[Backup] How to build and use Pansenti / meta-pansenti for Gumstix Overo Ironstorm

The original post Building small board systems with the Yocto Project is not available, here is the cached one from Bing search engine. It was said that from it could build a console image with working wifi connection on overo. I'm trying and test. If it works, I'll make it as my start point of further development on gumstix overo IronStorm.

Update: verified the wifi works fine, a very good start point for my project.

Building small board systems with theYocto Project

Last Updated on Wednesday, 02 October 2013 21:14

What follows are some notes for building custom BSP images for the Gumstix®, Wandboard andBeagleBone computers using tools from theYocto Project.

 

These are primarily developer images targeted at C/C++ and Qt developers.

 

We use images similar to these for our internal projects involving Gumstix Overos and Duoveros, BeagleBones, Wandboards and others. It's also the starting point forPansenti clients using Gumstix boards.

 

We use the Qt embedded images to develop and run Syntro. There is no X11 and no desktop installed on the systems, so don't expect to find that. They are designed for dedicated applications running usually a single user-interfacing application, typically a touchscreen, or often just a network server application like a web server or Syntro service likeSyntroLCam.

 

The meta-pansenti layer is continuously tested with Gumstix (Overo and Duovero), BeagleBones (Black and White) and Wandboards ( Dual and Quad), so it should always work on thosesystems at a minimum. It wouldn't be hard to add other boards (like the i.mx53 or RPi).

 

The Overo images can use either a 3.2 or 3.5 kernel. The 3.2 kernel is needed for custom McBSP drivers.

The Duovero images use a 3.6 kernel.

The BeagleBones use a 3.8 kernel.

The Wandboards use a 3.0 kernel.

 

The current Yocto Project version we are using is 1.4.2 (Poky 9.0.2). This is the [dylan] branch.

 

Ubuntu Packages

I've settled on Ubuntu workstations exclusively for now. Currently I'm using a 13.04 64-bit system.  I previously used Fedora without problems.

You'll need at least the following packages on your Ubuntu workstation.

• build-essential
• git
• pkg-config
• diffstat
• texi2html
• texinfo
• gawk
• chrpath
• subversion
• libncurses5-dev (for menuconfig)
• uboot-mkimage

 

I do the dpkg-reconfigure dash thing too, to change the default Ubuntu shell to bash. I'm not sure if that is still required.

 

Clone the repositories

Poky

Use the [dylan] branch

scott@hex:~ git clone git://git.yoctoproject.org/poky.git poky-dylan
scott@hex:~$ cd ~/poky-dylan
scott@hex:~/poky-dylan$ git checkout -b dylan origin/dylan

meta-openembedded

Use the [dylan] branch.

scott@hex:~/poky-dylan$ git clone git://git.openembedded.org/meta-openembedded
scott@hex:~/poky-dylan$ cd meta-openembedded
scott@hex:~/poky-dylan/meta-openembedded$ git checkout -b dylan origin/dylan
scott@hex:~/poky-dylan/meta-openembedded$ cd ..

meta-gumstix

Use the [dylan] branch

scott@hex:~/poky-dylan$ git clone git://github.com/gumstix/meta-gumstix
scott@hex:~/poky-dylan$ cd meta-gumstix
scott@hex:~/poky-dylan/meta-gumstix$ git checkout -b dylan origin/dylan
scott@hex:~/poky-dylan/meta-gumstix$ cd ..

meta-beagleboard

Use the [master] branch

scott@hex:~/poky-dylan$ git clone git://github.com/beagleboard/meta-beagleboard

meta-fsl-arm

Use the [master] branch

scott@hex:~/poky-dylan$ git clone git://github.com/Freescale/meta-fsl-arm.git

meta-fsl-arm-extra

Use the [master] branch

scott@hex:~/poky-dylan$ git clone git://github.com/Freescale/meta-fsl-arm-extra.git

meta-pansenti

Use the [master] branch

scott@hex:~/poky-dylan$ git clone git://github.com/Pansenti/meta-pansenti

 

The meta-pansenti/README.md file has the last commits from the dependency repositories that were tested. You can always checkout those commits explicitly.

 

Create a build directory

Some of the following are the conventions we use at Pansenti. They don't have to be followed explicitly. You'll know what you can change if you have done this before.

 

First setup a build directory. I tend to do this on a per board and/or per project basis just to keep straight the different projects I'm working on and so I can always quickly switch between projects.

 

I'll use a Gumstix Duovero build as an example.

scott@hex:~$ mkdir ~/pansenti-duovero
scott@hex:~$ cd ~/poky-dylan
scott@hex:~/poky-dylan$ source oe-init-build-env ~/pansenti-duovero/build
scott@hex:~/pansenti-duovero/build$ ls
conf

Customize the conf files

The oe-init-build-env script generated some generic scripts in thebuild/conf directory.
We want to replace those with the templates in meta-pansenti/conf. There is only one common bblayers.conf.sample, but separate local.conf.sample files for the other boards. They differ only slightly.

scott@hex:~/pansenti-duovero/build$ cp ~/poky-dylan/meta-pansenti/conf/local.conf.sample-duovero \
    conf/local.conf
scott@hex:~/pansenti-duovero/build$ cp ~/poky-dylan/meta-pansenti/conf/bblayers.conf.sample \
    conf/bblayers.conf
scott@hex:~/pansenti-duovero/build$ cd conf

Edit bblayers.conf

In bblayers.conf file replace the path /home/scott with the appropriate path to the repos on your system.

Edit local.conf

The variables you want to customize are the following:

• BB_NUMBER_THREADS
• PARALLEL_MAKE
• MACHINE
• PREFERRED_VERSION_linux-gumstix (Overo only)
• TMPDIR
• DL_DIR
• SDKMACHINE

 

BB_NUMBER_THREADS

Set to the number of cores on your build machine.

PARALLEL_MAKE

Set to the number of cores on your build machine.

MACHINE

Uncomment the line for the machine you want to build for. For this example

MACHINE ?= "duovero"

The ?= allows for declaring the MACHINE parameter outside this file in an environment variable if you want.

PREFERRED_VERSION_linux-gumstix

Only applies to the Overo for this layer. Uncomment if you need the 3.2 kernel instead of the default 3.5 kernel.

TMPDIR

This is where temporary build files and the final build executables will end up. Expect at least 35GB to be required. I'd opt for at least 50GB available.

The default location if left commented will be ~/pansenti-duovero/build/tmp. I usually put my TMPDIRs on dedicated partitions and often on another disk from the workstation O/S. Don't use a network disk or your build will take much longer.

If you specify an alternate location as I do in the example conf file

1. Make sure the directory is writable by the user running the build
2. Because of an bug in Yocto, the path cannot betoo short or thegcc build will fail. I haven't determined exactly how short istoo short, but/oe18 is too short and /oe18/tmp-poky-dylan-build is long enough.

    

DL_DIR

This is where the downloaded source files will be stored. You can share this among configurations and build files so I created a general location for this outside my home directory. Make sure you have write permission to the directory you decide on.

 

The default directory is ~/pansenti-duovero/build/sources.

SDK_MACHINE

Specify your workstations type, i686 for 32-bit or x86_64 for 64-bitsystems.

There are multiple MACHINE and TMPDIR settings in the example. Make sure only one of each is uncommented.

 

Run the build

You need to source the environment every time you want to run a build. The oe-init-build-env will not overwrite your custom conf files.

scott@hex:~$ cd ~/poky-dylan
scott@hex:~$ source oe-init-build-env ~/pansenti-duovero/build
### Shell environment set up for builds. ###

You can now run 'bitbake '

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-toolchain-sdk
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
scott@hex:~/pansenti-duovero/build

 

Those 'Common targets' may or may not build successfully. I have never tried them.

 

There are 4 custom images available in the meta-pansenti layer. Therecipes for these image can be found inmeta-pansenti/recipes-pansenti/images/

• pansenti-boot-image
• pansenti-console-image
• pansenti-qte-image
• pansenti-wt-image

All of the images are sysvinit only. No systemd.

pansenti-boot-image

A minimal booting image with networking support.

pansenti-console-image

A basic console developer image. See the recipe for specifics, but some of the installed programs are

• gcc/g++ and associated build tools
• git
• ssh/scp server and client
• wireless support
• kernel modules
• avahi daemon
• ntp daemon

It includes the pansenti-boot-image.

pansenti-qte-image

This image includes pansenti-console-image and adds Qt 4.8.4 embedded with the associated development headers and qmake.

This image also includes the SyntroCore v0.7 binaries as well as the headers and libraries for doing Syntro development on theboard.

pansenti-wt-image

This image includes pansenti-qte-image and adds Wt - a C++ Web Toolkit and the Boost headers and libraries.

pansenti-gst-image

This is a wandboard only image. It includes the pansenti-wt-image and addsGStreamer and the Freescale codecs for video and audio processing.

 

To build the pansenti-qte-image

scott@hex:~/pansenti-duovero/build$ bitbake pansenti-qte-image

 

Copying images to an SD card (Gumstix and BeagleBone)

After the build completes, the bootloader, kernel and rootfs image files can be found inTMPDIR/deploy/images.

The meta-pansenti/scripts directory has scripts to format and copy the files to a microSD card.

mk2parts.sh

This script will partition an SD card with the 2 partitions required for the boards.

Insert the microSD into your workstation and note where it shows up. You may have to look at your syslog. I'll assume/dev/sdc for this example.

It doesn't matter if some partitions from the SD card are mounted. The mk2parts.sh script will unmount them.

BE CAREFUL with this script. It will format any disk on your workstation.

scott@hex:~$ cd ~/poky-dylan/meta-pansenti/scripts
scott@hex:~/poky-dylan/meta-pansenti/scripts$ sudo ./mk2parts.sh sdc

You only have to format the SD card once.

copy_boot.sh

This script copies the bootloader (MLO, u-boot) and Linux kernel to the boot partition of the SD card.

This script needs to know the TMPDIR to find the binaries. It looks for an environment variable calledOETMP.

If I had this in the local.conf

...
TMPDIR = "/oe18/tmp-poky-dylan-build"
...

Then I would export this environment variable before running copy_boot.sh

scott@hex:~/poky-dylan/meta-pansenti/scripts$ export OETMP=/oe18/tmp-poky-dylan-build

Then run the script passing the location of SD card

scott@hex:~/poky-dylan/meta-pansenti/scripts$ ./copy_boot.sh sdc

copy_rootfs.sh

This script copies files to the root file system partition of the SD card.

You will need to create a temporary mount point on your workstation for the script to use. You only have to do this once.

scott@hex:~$ sudo mkdir /media/card

The script needs the same OETMP environment variable and anotherMACHINE variable that current can be any of the supported boardsovero, duovero, beaglebone, wandboard-dual orwandboard-quad.

The script also accepts an optional command line argument for the image type, eitherboot, console, qte, wt for all boards andgst for wandboards only. The default isqte.

And finally, the scripts accepts a hostname argument if you want the device name to be something other then the defaultMACHINE name.

The hostname affects the name that the device will use with avahi and theSyntroLCam stream name explained below.

Here's an example of how you'd run copy_rootfs.sh

scott@hex:~/poky-dylan/meta-pansenti/scripts$ export MACHINE=duovero
scott@hex:~/poky-dylan/meta-pansenti/scripts$ ./copy_rootfs.sh sdc qte duo1

 

The copy scripts will NOT unmount partitions automatically. If the partition that is supposed to be the on the SD card is already mounted, the script will complain and abort. This is for safety, mine mostly, since I run these scripts many times a day on different machines and the SD cards show up in different places.

 

Here's a realistic example session where I want to copy already built images to a second SD card that I just inserted.

scott@hex:~/poky-dylan/meta-pansenti/scripts$ sudo umount /dev/sdc1
scott@hex:~/poky-dylan/meta-pansenti/scripts$ sudo umount /dev/sdc2
scott@hex:~/poky-dylan/meta-pansenti/scripts$ export OETMP=/oe18/tmp-poky-dylan-build
scott@hex:~/poky-dylan/meta-pansenti/scripts$ export MACHINE=duovero
scott@hex:~/poky-dylan/meta-pansenti/scripts$ ./copy_boot.sh sdc
scott@hex:~/poky-dylan/meta-pansenti/scripts$ ./copy_rootfs.sh sdc qte duo2

 

Copying images to an SD card (Wandboard)

The Wandboard wants a different SD card layout then the Gumstix and BeagleBone boards, so the first two steps, partitioning the card and copying the boot partition use different scripts. The scripts are calledmk2parts_wandboard.sh andcopy_boot_wandboard.sh. The arguments to these scripts are the same asmk2parts.sh andcopy_boot.sh respectively.

The root filesystem copy to to the card uses the same copy_rootfs.sh as above.

Here's an example SD card copying session assuming a pansenti-gst-image built for a wandboard-quad in anotherTMPDIR

scott@hex:~/poky-dylan/meta-pansenti/scripts$ sudo umount /dev/sdc1
scott@hex:~/poky-dylan/meta-pansenti/scripts$ sudo umount /dev/sdc2
scott@hex:~/poky-dylan/meta-pansenti/scripts$ sudo ./mk2parts_wandboard.sh sdc
scott@hex:~/poky-dylan/meta-pansenti/scripts$ export OETMP=/oe5/tmp-poky-dylan-build
scott@hex:~/poky-dylan/meta-pansenti/scripts$ export MACHINE=wandboard-quad
scott@hex:~/poky-dylan/meta-pansenti/scripts$ ./copy_boot_wandboard.sh sdc
scott@hex:~/poky-dylan/meta-pansenti/scripts$ ./copy_rootfs.sh sdc gst wq1

After boot

The pansenti-qte-image runs SyntroLCam on startup.SyntroLCam is a Syntro USB web camera application.

If you plug a camera into the USB Host port of the board, you will be able to view streamed video from the board using SyntroView.

 

Some screenshots of a running SyntroLCam/SytnroView setup can be found here: Gumstix, RPis, BeagleBones, Action!.

 

SyntroView is easily built on Unix based systems that have Qt installed. VS2010 solutions are provided to build on Windows machines.

To disable SyntroLCam on startup, edit /etc/default/camera.

 

BeagleBone only

Because we are primarily using the BeagleBones to test some sensor boards for anotherproject, there are some customizations in the Pansenti images that may disable other cape boards.

These are the changes

• /dev/i2c-1 references the I2C1 bus and /dev/i2c-2 references the I2C2 bus.
  
  This differs from the default kernels for the BeagleBone where /dev/i2c-1 references theI2C2 bus andI2C1 is not used.
  
• GPIO1_16 (gpio48), GPIO1_17 (gpio49), GPIO1_28 (gpio60) are exported as output pins.
  GPIO3_19 (gpio115) is exported as an input pin.
  
• The internal ADC pins are enabled.

 

The GPIO and ADC are enabled by a simple sysvinit script called /etc/init.d/board-setup.sh that is run at boot.

 

The I2C changes are done with a kernel patch that can be disabled during the build.