Friday, June 5, 2009

Working on the development side of things

For the last several weeks I have been working on the development side (software implementation) for the Overo series of COM (Computer On Module) units. This has been rather an interesting experience as the Overo line is a rather new (read: bleeding edge) computer system so the software is being created in a very fast pace in terms of development. Unlike a Windows based machine you have to run a development system to implement different applications or make changes to the Linux kernel for different hardware drivers if they are not active in the factory installed version. You can installed pre-compiled applications using an application installation program but if the application is not already built or you are wanting to use a linux hardware driver that is not already factory installed then a development system is a must. Besides, it can be very educational to see how things are done under the hood, so to speak. The development system chosen for the Overo line by Gumstix is called OpenEmbedded which is an open source development system for embedded computer systems (interesting - wonder where they came up with the name?).

Until now I have worked with cross-compiler systems where you were actively involved in the cross-compile process, such things as creating and modifying 'make' files (used to setup dependencies, setup variables used, call the different development applications and so on) to installing the different cross-compiler and library files and compiling the different parts of the development system toolchain. Most of the development systems I have worked with also require "switching" to a virtual filesystem for the actual cross-compilation process to protect the underlying operating system otherwise it is very easy to trash the operating system and crash the development computer system!

In using the OpenEmbedded system that has totally changed! Most of the 'grunt' work is now handled by the OpenEmbedded system itself, from downloading the different parts needed to cross-compile C source code, compiling the cross-compiler tools and software libraries, installing the different parts used in the proper locations within the development computer's filesystem, downloading the different applications and Linux kernels used for creating the operating system and applications, determining the different dependencies (which parts need to be compiled in what order so the different parts and applications can 'find' the needed links and library headers) - then - building the whole operating system and applications along with the filesystem, boot-loaders and startup scripts needed to run the system and applications on the Overo line of computers! Gotta love that! Now - the learning curve for OpenEmbedded is steep (at least it is for me) but is very doable and if you do become accomplished at creating bitbake recipes (recipes are the script files that tell BitBake how to accomplish something) you can build most any application without the laborious task of writing 'make' files.

Now - this is the part most here will find difficult. The OpenEmbedded system runs on Linux systems ONLY! Part of the reason for this is most of the embedded computer systems working with open source are based on Linux so it makes sense to develop in the same environment as the target system operating system is going to be. OpenEmbedded will NOT work in Windows (unless you are running a Linux system on a Windows based machine)! This may change in the future but I would rather stay in the Linux environment so as not to muddy the water too much - just think of the headaches you might encounter trying to run Windows compilers to build Linux operating systems on computers that have a whole different architecture from the machine the target system is targeted to! This is not as bad as it might seem! My home development system IS a Windows based system ( I like gaming and most of the games I play are not written to run in Linux!) but I can run Linux on the system without any issues and still perform other tasks in Windows at the same time.

How can this be you ask?

Simple - in one word - Virtualization!

I use VMWare's free VMWare Server to run different "Virtual" computers on my Windows system. This allows me to have multiple computers exist on the same hardware and I have enough computer resources to run Windows (XP) and three or four virtual machines at the same time on my machine. Of course it can get confusing at times but the capability is there (grin). Now there is a caviat to using a virtual environment... you want to have enough physical resources on your machine to allow the virtual machine to run decently. In other words you want to have at least 1-gig of RAM and at least 100-Gigs of hard drive space available otherwise if you have only minimal RAM in the machine the virtual machine may not have enough memory and will start swapping to the virtual drive (this really bogs things down) and if you don't have enough hard drive space you will "run out" of virtual hard drive space in the virtual machine - this is worse than too little memory! Having said that here is what I did to create a development system for the Overo line.

Here are the (very) generalized steps I used:
  • Downloaded the Free VMWare Server and installed it on my computer system. The VMWare server also needs the Java Runtime package so I downloaded that as well then installed it on my machine per the instructions on the Java website.

  • Once I had the VMWare Server installed I opened the VMWare Server application and created a virtual machine for a Linux System. I setup the memory for 512-Megs to start and configured the hard drive storage for 80-Gigs of space. For the 'network' settings I use 'bridged' mode so the virtual machine would use the computer's interface and the virtual operating system would be able to use DHCP to obtain the information needed to connect to my home network automatically. The configuration for the virtual machine is stored on the hard drive a several files (this includes the virtual hard drive image) which makes saving copies very easy - just copy the files and you have a backup!

  • The Linux environment I use is Ubuntu Linux workstation. I downloaded the Ubuntu 9.04 version (latest stable version) as an ISO file (CD image file) and saved it on my machine in the directory where I built the virtual machine for the development system. The reason you save the ISO image in the same location as the virtual machine storage is very simple - in the VMWare Server environment you can only "see" items that are stored in the virtual machine directory!

  • To install the Ubuntu 9.04 Workstation software in the virtual machine you need to configure the CD-Rom drive settings in the VMWare Server settings for the virtual machine to use the ISO image as the CD-Rom. This is very easily done during the configuration of the virtual machine as there is a question during the configuration as to what to use for the CD-Rom - you just select the Image setting and browse to the Ubuntu ISO image file previously saved in the virtual machine directory - this is the only place you can browse from within the VMWare Server which is the reason I saved the ISO file there.

  • Once the virtual machine was configured I started the virtual machine and opened a virtual machine window. The Ubuntu system starts up just like the CD version - I selected the "Install Ubuntu" selection to install the Ubuntu system in the virtual hard drive. After answering a couple of questions (keyboard and mouse type, timezone, user name and password, etc ) the Ubuntu installer fires up and completes the installation of the Linux system into the virtual hard drive and then waits for you to "remove" the CD-Rom media and reboot the virtual machine.

  • To "unmount" the Ubuntu ISO you just edit the CD-Rom settings for the virtual machine in the VMWare Server and set the CD-Rom to either none or the physical one in your machine (personally I set it to the physical one). Ubuntu will complain since it was running from the ISO image but just answer "yes" to the question then reboot the virtual machine. When it comes back up you will be running in Ubuntu 9.04 (or whatever version you are using) Linux in a virtual environment!

  • After Ubuntu was installed on the virtual machine I performed a system update to download any new updates for the system. While this is not a hard requirement I like to have a system that is fully up to date before using it for development.

  • The next step is to install the Openembedded development system in the virtual machine. I used the steps located on the Overo Development Website (Link) but there are a couple of differences for the Ubuntu 9.04 version:

    1. One has to do with the notes on the webpage where the instructions state to add the following to the sysctl.conf file; 'vm.mmap_min_addr = 0' . The sysctl process does not recognize this command so I left it out where the instructions stated to place the command.

    2. A second item has to do with the 'way' the development system operates in the current default download of the OpenEmbedded system. BitBake (the MetaData executor) and OpenEmbedded use Python ( a programming language) to implement the development system - the default download configures the system to use "Python" whereas the Ubuntu system uses "Python-2.6". How can that be an issue - it is as the system gets 'confused' as to which version to use - talk about making a mess! Also, it is very difficult (at least for me) to determine exactly what fails during a build when this confusion occurs. The answer to this issue is really simple - just update the OpenEmbedded development system. If you follow the instructions to install the OpenEmbedded system I listed earlier then all you need to do is go into the org.openembedded.dev directory and type the following command: git update which downloads the current updates for the OpenEmbedded system. One of the updates corrects the Python "confusion" issue so things work properly after the updates are done. NOTE: I am being metaphorical here when I say it is a "confusion" issue but it makes it easier to describe (grin).

    3. When you reach the point where you perform your first build be prepared to wait a while for it to complete! On my system, connected to the Internet at 8-mbit/second it takes about 12 hours for the development system to download all the parts needed and compile the console (CLI) version of Linux for the Overo computers. Once you have performed a successful first build the time is much shorter as all of the development parts have been downloaded and compiled and all of the source files for the console version are on your virtual hard drive.

  • Once the development system has been installed and you have built the first recipe (omap3-console-image) successfully you can build the GUI desktop version for the Overo line by using the 'bitbake omap3-desktop-image' command in the overo-oe directory of the developement system. Of course, if you have not built the development system and are just reading this that last sentence probably will make absolutely no sense what-so-ever! (grin). A note - there are a great many parts to the GUI version that have to be downloaded so this first build also takes a fair amount of time! On my system the combined first build of the console and GUI versions took about 26-hours total to accomplish. Of course, your time will be different based on your computer hardware and your internet connection.
If you do decide to setup a development system for the Overo line I would advise you insure you have enough memory and hard drive space! On my system the GUI version of the Linux operating system for the Overo line takes about 22-gigs of space. If I wanted to build ALL of the applications and drivers currently available it would require around 40 - 45 gigs of space to store all of the information needed.

I am thinking if there is some interest I could create a VMWare image of the development system with the OpenEmbedded and BitBake applications installed. The VMWare image would already contain the all of the OpenEmbedded updates at the time of the image build. All you would need to do is download and install the VMWare Server software, install the image then perform the console and GUI bitbake builds to have a Overo development system of your own. Let me know what you think...

3 comments:

  1. Hi Gary,
    I also have bought an overo fire + summit board. But I am having trouble to get bluetooth working.
    Is bluetooth working on your setup?

    ReplyDelete
  2. Thanks for sharing your work ! Open source, diminutive, powerful, versatile, Great !

    ReplyDelete
  3. Sorry I have not posted anything further lately - I had a medical emergency cropup! Acute appendicitis that was perforated! Needless to say I underent surgery on June 17th and am still recovering in the hostpital at the moment. I would NOT recommend this for anyone. Hopefully I will be out in a couple of days and get back to the tinkering again!!!

    ReplyDelete