Update: This document is being rewritten in the file openembedded. We might delete this file soon.
Update : OE already works and we decided to use the Angstrom Distribution. We will publish the details soon. This instructions are just for beta testers, please write us if there's something wrong, or make changes/notes on this wiki.
Installation notes to build Openembedded based system
This document explains how to compile OpenEmbedded for the boards free-ecb-at91 and ecb-at91-v2.
This document is a work in progress. It was started by Stefano Parusso. Thanks.
OpenEmbedded is a very good development environment allowing users to target a wide variety of devices, for more informations look at the OpenEmbedded's home page. Each step is well documented, a rapid guide follows for impatient people on how to install everything needed.
Required software
Refer to the software requirements to check if your development system is adequate, the first tested development distribution on which this document is based is Kubuntu, Debian GNU/Linux can be another good option.
To download OpenEmbedded sources, monotone is required. On a stable Kubuntu distribution an old version of this package is available; however I suggest to download a more recent version from the unstable/testing branches. A good way to do it would be to use the latest binary format provided by the OpenEmbedded team. Building monotone could be hard, so you might want to use a binary.
The heart of OpenEmbedded is a Python program called BitBake. For download instructions refer to the Getting started guide of OpenEmbedded. To install it, from install directory:
./setup.py install --prefix=/usr/local --install-data=/usr/local/share
Before beginning
As stated in the Openembedded guide, the install procedure requires a /stuff/ directory to chroot within. It's warmly suggested to create the directory structure in a user's home directory. This approach simplifies chrooting and env variable exporting, through $HOME and $BBPATH (as defined in .bash_profile). Don't try to define more variables. Some guides say that you should define the variable $MACHINE, but please, don't do that. Once everything has been set, you can type:
su - openembedded
after logging in at least once. Once you created the new user (in this guide We assume it to be named openembedded), you need to log in and change .bash_profile adding:
export BBPATH=~/org.openembedded.dev # Try to use an absolute path here, like /home/oe/org.openembedded.dev
Assuming to use patches and procedure explained above, this will be the only modification needed to setup a complete development enviroment.
Tips
If you have a lot of disk space, you might want to maximize ccache usage.
ccache -M 50G ccache -L 10000000
Let's play
Login as user openembedded; the first step is getting the latest openembedded monotone database sources:
$ wget http://www.openembedded.org/snapshots/OE.mtn.bz2 $ bunzip2 < OE.mtn.bz2 >OE.mtn
Update the monotone database (this might take a while):
$ mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev
Check it out:
mtn --db=OE.mtn checkout --branch=org.openembedded.dev
cd into main directory and download the integration file from here:
cd org.openembedded.dev tar -jxpvf openembedded_integration_rev1.tar.bz2
go back to home directory and launch base image compiling:
cd ~ bitbake ecboe-image
the compiling/downloading processes usually require lots of time. This delays can be lowered if a high-bandwidth connection or a fast processor is available. If everything goes well, looking in:
~/tmp/deploy/glibc/images/
you will find an an image file like this:
ecboe-image-ecbat91.tar.gz
that's a simbolic link to last compiled version. Just ready to be downloaded on SD card...
Packages administration
Is possible to have a list of available packages by accessing org.openembedded.dev/packages, each sub-directory rapresents a possible package, the most common mode to compile the related ipk is access to home directory and type:
cd ~ bitbake PACKAGE_NAME
to clear and remake package:
cd ~ bitbake -c clean PACKAGE_NAME
If you need a fast way to create a new package bypassing global database reading (useful for debugging):
cd ~ bitbake -b org.openembedded.dev/packages/PACKAGE_NAME/PACKAGE_NAME_X.X.X.bb
in the same way is possible clean the package:
cd ~ bitbake -c clean -b org.openembedded.dev/packages/PACKAGE_NAME/PACKAGE_NAME_X.X.X.bb
Useful directories:
root file system: ~/tmp/rootfs
cross compiler: ~/tmp/tmp/cross/bin
Filesystems
Standard way
For biggest part of embedded systems using flash (NAND or NOR technology), the best choice to download a filesystem is create a jffs2 image and put it in a dedicated partition; if there's no space left on flash and any kind of memory has to be used for filesystem storage, the best way to guarantee a good stability is by using a journaled file system. There are four mature ways to do that:
- reiserfs
- jfs
- xfs
- ext3
each solution has limits and benefits, I remand to this article for benchmarks considerations, the focus, if you have limited space to use for filesystem, is the dimension of journaling structure emploied on solid small storage memories, below a table with occupation report just after formatting in standard way (no options specified):
Type | 1k-blocks used |
|---|---|
reiserfs | 32840 |
jfs | 196 |
xfs | 144 |
...and occupation after typical minimal filesystem download:
Type | 1k-blocks used |
|---|---|
reiserfs | 40140 |
jfs | 9568 |
xfs | 8976 |
Ext3 in during reports generation was not tested because all others are older than ext3 and designed for journaling in mind, ext3 is an extention of etx2 including journaling, but imho is not stable and mature like others.
considerations:
- reiserfs is one of the best and common filesystems for desktop and server environment, it introduces a big overhead during format, so it could be not so indicated for solid memory formatting.
- jfs is good and stable, already used for working solutions in past.
- xfs seems to be the most complete solution, interesting real time support in last releases.
Make your considerations and keep in mind to include specific kernel support to generate a working image after format operations.
Zero state machine
If the target of your system is having a trusted and stable base system, the best way to do that is make a readonly partition and, at every new restart, make parts available in rw by coping perts of ro on memory reserved locations mounted over existing directories. Possible ways to do that are:
- cramfs
- squashfs
- union file system
- tmps for memory rw dynamic space allocation
...............TO BE CONTINUED.
Packages download
Base image download from Hamradio ir3arp.net server, last image uploaded: ecboe-image-ecbat91.tar.gz.
Access to pre-compiled packages from: Angstrom distribution
To do
- How to create new ipk
- Use compiled toolchain for external operations
Last update: 2007-08-07 (Rev 400)