OpenZipit Z2 Development

OpenEmbedded distribution Linux for the Zipit Z2

The goal here has been to move beyond the simple command line interface that was only possible on the Z1 into a full graphical environment (GUI) on the Z2. To make that possible, there are a number of hurdles which have to be surmounted:

We need a desktop. Either GPE or OPIE is possible (using MatchBox).

We need some sort of "mouse" input, possibly the joystick?

Both of these pose some serious issues, but, these are software issues. We do not have to modify the Z2 to make it usable! OpenEmbedded has advanced to the point where it can be used as a serious tool to build-out a suite of software to compose an effective GNU based operating system. The joystick possibly can be used by rewriting the pxa-keyboard kernel module, then using it in conjunction with tslib or the uinput device.

So far, all I have been able to do is to tinker with the Z2, nothing useful has come about other than to get OE (OpenEmbedded) together to build the two GUIs. That, in itself, is something of a miracle! Well, to be fair, I was using the development branch (org.openembedded.dev) for a while and it was very frustrating. I had much more success when I switched over to the stable branch (org.openembedded.stable).

I've run both desktops and had little success at getting beyond their opening screens. Where I have had some success is to run the X-org server (XFbdev) directly and then manually launched desktop apps. This is what I shall show you now, how to setup and build an image, then run the terminal app (similar to Konsole).

I hope you take this work further as I just don't have the time right now to "play".

TopSetting up OpenEmbedded on your Linux box

I would believe that any of the distributions should be able to get OE working. Ubuntu is, currently, popular, and that is a debian based system (I may be wrong about that). I, personally, run Mandriva 2008 on both my dev boxs. The primary machine that I build with is a: Intel Q6600 (Quad) with 8Gig of DDR2 RAM on a RAID-0 volume across six SATA-300 drives. YMMV ;-)

BE AWARE! OE is not something like buildroot where a couple hundred meg of drive space is needed for a simple O/S build. OpenEmbedded is a serious tool which is used to build Linux DISTRIBUTIONS, not teensy romable images that merely get you to a bash prompt. Typically, you will need 10Gig free if you will want to build the gpe images.

OE effectively builds a debian operating system for the Zipit. To do this, no assumptions are made about what cross development tools and development libraries is assumed. EVERYTHING is built from scratch (source) and placed into a virtual development environment. The megabytes pile up very quickly into gigabytes of drive space.

For example, it takes nearly 4Gig of drive space to build the base image. 'base-image' consists of 73 source packages, ranging from development tools (such as: GNU binutils, glibc, automake, etc.) to the system binaries, libraries and utilities which make up the bootable image. The GUI images, minimal-gpe-image and gpe-image, can easily surpass 8Gig, with 294 source files.

Why is OpenEmbedded so big? Well, you have to understand that OE makes NO ASSUMPTIONS about what is currently installed on your computer. Anything that is needed is built inside the tmp-zipit2-angstrom directory. That includes mundate utils such as curl, wget, and so forth. The OE.mtn database alone (OE.mtn.bz2, OE.mtn, meta/) consume 574Meg, source tarballs about 347Meg, ...

TopGet the Files

I make this really simple, we use a Makefile to set things up. Grab the tarball , unpack it (tar jxf ZipitZ2-openembedded.tar.bz2), 'cd ZipitZ2', then type 'make'. The basic files will then be fetched from the web and your development environment will be setup. I hope you have a fat pipe to the web, OE needs a lot of large files!

CAUTION! MAKE ABSOLUTELY CERTAIN that you have NO SYMLINKS in the path to this directory! OE (bitbake) does strange things across symlinks: it quietly messes on itself.

Also, YOU DO NOT HAVE TO BE ROOT TO BUILD IMAGES! Actually, building images as other than a USER will fail. You must only become superuser to access the block devices on your computer to partiton the SD card and install images to them.

TopA Typical Install

[tom@slushy ~]$ tar jxf ZipitZ2-openembedded.tar.bz2

[tom@slushy ~]$ cd ZipitZ2

[tom@slushy ZipitZ2]$ make

Searching for prior installation of bitbake...

*** installing a copy of bitbake v1.8.10

Searching for prior installation of monotone...

*** installing a copy of monotone v0.38

fetching the OE database now...

extracting OE database...

*** installing OpenEmbedded database, 'stable' branch

mtn: doing anonymous pull; use -kKEYNAME if you need authentication

mtn: connecting to monotone.openembedded.org

mtn: finding items to synchronize:

mtn: certificates | keys | revisions

mtn: 61,951 | 66 | 20,409

mtn: bytes in | bytes out | certs in | revs in

mtn: 1.3 k | 1.5 k | 0/0 | 0/0

mtn: successful exchange with monotone.openembedded.org

substituting 'collie' with 'zipit2' for oabi

*** install local.conf

*** install machine configuration file.

[tom@slushy ZipitZ2]$

TopBefore You Build an Image...

There are a few things you need to know. First, let us look at the final directory contents. Here is what you should see:

[tom@slushy ZipitZ2]$ ls

bitbake-init-build-env* Makefile misc/ OE.mtn.bz2 tmp-zipit2-angstrom/

build/ meta/ OE.mtn sources/ zipit2-angstrom-pkgs/

The "build" directory holds the 'local.conf' file which governs how bitbake finds things and how many processes to spawn during a build. I have set it to 2 processes which should be for a single core system. If you have a dual / quad core, you can take advantage of a quicker build by adjusting 'PARALLEL_MAKE' and 'BB_NUMBER_THREADS' to twice your core count (e.g. Q6600 would be '8').

The 'bitbake-init-build-env' script will temporarily modify the PATH and set the BBPATH variables in your shell environment.

The purpose of the 'Makefile' and 'misc/' directory is for your initial setup. You may delete these if you wish.

'OE.mtn' and 'OE.mtn.bz2' must remain, they are the 'recipe' list from which the stable branch is extracted (meta).

'meta/' is the master list of recipes. Builds are done according to the directions found within their contents.

'sources/' is the tarballs, etc., downloaded from the web to build each package within the recipie.

'zipit-angstrom-pkgs/' contains package (recipie) definitions which will override those found in the 'meta/' directories.

'tmp-zipit2-angstrom/' is the directory where all the build activity will take place. The sources will be unpacked in there and compiled there as well. The cross development compiler, binutils and other tools also will reside there.

At any time, you may delete the 'tmp-zipit2-angstrom/' directory to start over. This should not be necessary, but, if you need to conserve disk space, you can. The images built will be lost, but can be re-done at a later time.

At any time, you may delete the 'sources/' directory to save space. These files will simply be downloaded again later and the directory recreated. However, keep in mind, that websites can, and do, disappear from time-to-time. You may want to keep this directory in a save place? You can edit the 'local.conf' and change it's location...

A FINAL NOTE: The reset for the Z2 is a tiny little hole in the left side, towards the front of the headphone jack. Poke a paperclip in there and it will power off the Z2.

TopBuilding Images

There are four images that you will find useful, to varying degrees:

'base-image' is a basic text only system that gives you a text command console. You simply login as 'root' (no password). Wifi should be working, and if you create a user with a password, then dropbear will allow you to login via the Wifi link.

'minimal-gpe-image' is perhaps the most interesting. This is a basic GUI and is what I have been focusing on. The Wifi will let you login as a user. I suggest that you edit '/etc/init.d/gpe-dm' and comment out the line that says '/usr/bin/gpe-dm'. If you let the GUI start, it takes you to a login screen that is missing something: it keeps restarting after entering the username / password.

'gpe-image' and 'opie-image' also build fine, but are useless (right now) to varying degrees. 'gpe-image' clobbers the unix PTYs and you cannot login via Wifi. 'opie-image' is entirely touchscreen based, I have yet to get past the splashscreen of 'touch anywhere to begin'.

OK! Let's build the 'base-image' as an example of how to do everything and boot the Zipit Z2 into a linux console (system).

[tom@slushy ZipitZ2]$ source bitbake-init-build-env

### Shell environment set up for project builds. ###

[tom@slushy ZipitZ2]$ bitbake base-image

On my Q6600 system, this build takes 31 minutes when downloading all the sources over a 15Mb/s cable modem.

Reportedly, a Thinkpad T40 (1.6Ghz) with 768 Meg of RAM can build the base-image in 164 minutes (2.7 hours).

NOTE: the 'source bitbake-init-build-env' only needs to be done one time within the console to setup the shell (/bin/sh) environment. It is not necessary to re-run it during a shell session. Oh! If I haven't mentioned it before, all my work is done from within the KDE using Konsole, you don't need to drop to the CLI text console(s).

TopProblems During a Build

Your first attempt at an image build will likely fail with bitbake complaining of some development utilities, and / or libraries, that your system is missing. Examine the error message and install the appropriate packages. One package that it doesn't complain about is the (g)libc-static-devel libs (libc.a), install this now.

Once the build gets underway, it will start downloading source tarballs from various websites. Go make dinner, see a movie, mow the lawn... OE takes time to do it's thing, expect 2..4 hours on a modest dev box (3GHz single core with 2Gig of RAM).

You will probably find websites that are offline, or have moved the source file that you need to some other directory. This can be easily overcome. You need to locate the exact package named from somewhere and download that source tarball. Place that into the 'sources/' directory. Next, you create an MD5SUM file for the file you just put into 'sources/', do it this way:

[tom@slushy ZipitZ2]$ md5sum sources/zlib-1.2.3.tar.bz2 | cut -f1 -d\ > sources/zlib-1.2.3.tar.bz2.md5

The md5sum number is only needed within the file, not the filename component.

During the build, you will see messages such as 'NOTE: Running task 89 of 584 ...' being printed out. '584' is how many TOTAL tasks need to be done. From this, you can get a vague idea of how long your build will take...

While using a multi-core dev box, a process may have failed waaaaaay back! Go back through the Konsole buffer and loate the first ERROR message. That message, or a few ERROR messages down, will tell you to 'ERROR: see log in ...' a log file. Examine that file to determine what action to take. Usually it is a website that is down for maintenance or moved your source file to somewhere else. If all else fails, keep running the build, 'bitbake base-image' until it won't run anymore or you find the logfile.

TopA note about BitBake builds

Typically, I have more than one project that I am working on using OE. Sometimes I even have several seperate directories for the same project, I have about 5 right now for the Zipit Z2. Not all are part of the Z2 project, most of these have been steps along the way that I have taken while learning to use OE.

The point is this, you can easily have more than one OE project and can quickly switch from working on one to the other. The bitbake-init-build-env script is designed to let you do this. 'source'ing that script will not only set your PATH and BBPATH vars to the current build directory, but will ensure that you don't have conflicting entries within them. Please remember to source that script whenever you switch projects, if in doubt, just source it again.

Zipit Z2 OpenEmbedded