Developing with the CerfCube

It's important to realize that the CerfCube is not meant to be an end product, as shipped. Rather, it's intended to serve as a conveient (and cute) platform to make it easy for original equipment manufacturers (OEMs) to evaluate Intrinsyc's CerfBoard SBC, develop products based on it.

An initial look at the CerfBoard's development model shows it to have a simple and straightforward design, providing an easy-to-use environment while still providing access to the lower-level details.

The CerfCube system configuration model at first seems chaotic, but one quickly becomes acclimated to the environment. Setting up the host for cross-development is an annoying process — it consists of manually untarring nine files and running some scripts. This installs the source code for the target system, the StrongARM cross-compiler and binutils (for an x86 cross-development host), and various build scripts and tools.

The installation process deposits its files throughout the development host, and there is no simple way to uninstall them. The installation process could be improved by providing RPMs or .deb files; or better, just make the installation one big tar file that installs all its files in a user-selected location. Intrinsyc reports that they plan to provide uninstallation scripts with the next release of the toolchain.

Making mod's

Intrinsyc's documentation for modifying the system software is clear and well laid out, and they provide helpful scripts to simplify the process. In general, you simply modify the default sources, run a script to rebuild the image, and download to the CerfCube using TFPT or BOOTP.

You need a serial connection to the CerfCube's monitor program to initiate image transfers, and an Ethernet connection to transfer the data. This can be done through a hub, or by using the Ethernet crossover cable which Intrinsyc helpfully provides, which lets you make a direct connection between your desktop computer and the CerfCube.

Modifying the kernel is a matter of making the changes in the source directory, running a script to build a new zImage file, and downloading the image to the CerfCube using either TFTP or BOOTP. This process is well documented, and works well. The kernel provided with the CerfCube is 2.4.0, with Russell King's ARM patches and Nicolas Pitre's StrongARM patches applied.

Software organization and packaging system

The system has two memory-based filesystems. rootdisk is uncompressed from flash into RAM and mounted as /. Packages can be added to this filesystem fairly easily; again, Intrinsyc has provided helpful scripts to accomplish this, and the process is well documented. usrdisk is a flash-based filesystem that is mounted read-only directly as /usr. Modifying this filesystem is a simple matter of remounting the filesystem read-write, making the changes, and remounting read-only.

Intrinsyc uses a simple but functional packaging system in some ways similar to that used by Midori Linux. The unmodified source tarfile is provided for each package, along with a patch file with CerfCube-specific modifications, and a script to build the whole thing. These three files are placed in a package-specific directory. Thus, for example, the joe-2.8.color.5.dir directory contains the unmodified joe-2.8.color.5.tar.gz, a patch file called diff-joe-2.8.color.5.dir, and a script called 'build'. Building and installing new or modified packages is a matter of running some scripts using a well-documented sequence.

• Part 1: The onward march of embedded Linux
  
• Part 2: Developing with the CerfCube
  
• Part 3: Conclusions

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.