Gumstix Development Tips

Last Updated on Friday, 04 November 2011 22:56

A collection of practices I've adopted for Gumstix OE development.

 

These are practices that keep me productive. YMMV.

 

1. Create branches of the OE git tree for your projects.

After following the steps to setup up a working OE development environment for Gumstix, you may as well take advantage of the fact that you now have a full OE repository on your system and use git for what its designed.

The steps to create a your own branch are simple.

cd ${OVEROTOP}/org.openembedded.dev
git checkout -b my-project

Now you can make any changes to recipes, config files, patches you want in your own OE branch and not worry about them being clobbered.

If and when you want to pull the latest changes from the master Gumstix OE repository you first switch back to the overo branch and then do your pull.

cd ${OVEROTOP}/org.openembedded.dev
git checkout overo
git pull

Now before you go further, do some testing to make sure that this latest pull doesn't break anything your system requires. I use Tip #2 to help with this.

When you are satisfied that the pull didn't break anything, pull those changes into your personal branch.

git checkout my-project
git merge overo

Of course, you can have as many personal branches as you want. Branches are cheap as far as disk space and very fast to switch between.

Learn git.

 

2. Maintain multiple OETMP directories for testing and production.

Disks are cheap compared to time. I have one dedicated disk for OETMP directories that I cycle between by changing the OETMP variable in ${OVEROTOP}/build/conf/site.conf as necessary.

I always keep known good OETMP directories to go along with my development branches from Tip #1 that I don't ever want broken. For example, I tend to keep each of my customers in their own OETMP since they frequently have particular kernel versions and configurations which are not conveniently switched in OE using a single OETMP.

When I am testing a new git pull, I always change to an OETMP directory where I don't care if it breaks.

This also gives me a heads up whether the latest OE is going to require a complete rebuild of OETMP. If it does, I can choose to do the rebuild at my leisure.

A single $100 terabyte disk can hold more OETMP directories then anyone probably needs. In reality, it's rare that an OETMP directory uses more then 20 GB for any of my projects anymore (see Tips #7 and #8). I use the same disk for multiple OETMP directories for my beagleboard builds also.

The important thing is that using this and #1, at no time is my development ever held up because of an upstream OE change or breakage. My development environment is always under my control.

 

3. Put OETMP directories on their own disk partition.

To go along with Tip #2, put the OETMP directories on their own partitions. That way wiping one is just a matter of umount, mkfs, remount, change permissions.

For example if I had an OETMP on /dev/sdb1 mounted as /oe:

sudo umount /oe
sudo mkfs.ext4 /dev/sdb1
sudo mount /oe
sudo chown -R scott:scott /oe
rm -r /oe/lost+found

This takes around 30 seconds. Much faster then trying to delete the contents of an OETMP directory with rm -rf.

 

4. Don't create a user.collection directory for your customizations.

Use Tip #1 instead and keep your customizations inside the same git repository on one of your own branches. This way you can track them along with the rest of the system they will be a part of.

There might be some value in the user.collection idea when you need to pull code from external projects not part of any OE repository. Maybe...

For your own work, don't use user.collections. Use a git branch.

 

5. Don't use bitbake for development. It's okay for deployment.

Bitbake is ridiculously slow for development for userland, kernel or u-boot code and I work on a pretty fast machine.

Instead, directly invoke the cross-build tools that OE generates.

For userland code, a Makefile is all that's needed to point at the cross-compiler, headers and libs.

For kernel or u-boot code, a simple file to setup an environment will work.

I usually test kernel patches for compilation outside of bitbake, but I do use bitbake to package up the new kernel and modules for the rootfs. That's for the convenience of the /lib/module deployment. I know how to do it manually. It's just faster for me to use bitbake in this case.

For out of tree kernel module development, I never use bitbake.

There are examples for both Makefiles and environment files elsewhere on this site, on the gumstix dev site and many other places on the web.

 

If you are a contractor billing by the hour, then maybe bitbake for all development is the way to go ;-)

 

6. Invest in a decent development machine

This isn't feasible for everyone, students and hobbyists I know, but a relatively small investment on a solid development machine can save you loads of time.

As an example, a full rebuild of OETMP for my working images takes only around 30 minutes. The machine, a 4-core system, cost me less then $800 to build last year. It's surely cheaper now. I'm probably going to upgrade to a 6-core system soon.

You hear stories on the Gumstix mailing list of people waiting significant portions of a day or even days for OETMP rebuilds. Ouch!

 

7. Develop using tftp and an nfs root for your gumstix.

If you can manage it, do your development with a Tobi or Chestnut43 or any Gumstix expansion board that has a NIC you can use for NFS boots.

This way all your code deployments are simple file system copies from one location on your workstation to another. A huge time-saver, particularly for kernel or kernel module work.

The steps involved for workstation and gumstix u-boot setup are a one-time ordeal, fairly well documented I think.

There are instructions on this site and on the Gumstix User Wiki site.

 

8. Create custom images.

It's highly unlikely you require every application that comes in the omap3-console or omap3-desktop images or any of the stock images in recipes/images/. Don't be afraid to whack away at these image recipes directly or make your own image recipe based on an existing one.

You'll have much less chance of upstream breakage if you reduce the dependencies to what you really need and it will significantly speed your build times.

Tip #1 lets you do this with impunity.

 

9. Learn to use the OE dependency files generated with bitbake -g (--graphviz)

Using the depends.dot and task-depends.dot generated by the --graphviz option to bitbake is relatively new to me, but I think it is going to be a favorite tool. No more guessing why an OE build is building what it is.

One hint, don't bother trying to open these .dot files with a graph editor. The generated pictures are very big and not too useful. That's if the tools don't crash generating the images.

Use a simple text editor to look at the .dot files. The files formats are easy to enough to figure out.

I do have some python scripts to help condense the data a bit and simplify searches, but even those are of limited use. Here's a link to where you can find them. I'll be posting more soon - oe-deptools

 

Summary

I am sure I forgot a few things that are just habits and I left out any mention of scripting various steps of the development process.

I just wanted to point out that working with gumstix using the OE tools doesn't have to be as hard as the user lists would have you believe.