Getting started

For an LSP supported target, installation and configuration are straightforward, if somewhat tedious. The Installation and Setup Guide is organized fairly well, at least if you are using one of the supported SBCs.

Hard Hat 2.0's supported host Linux distributions are somewhat limited: Mandrake 7.2, Red Hat 6.2 and 7.0, SuSE 7.0, and TurboLinux Workstation Pro 6.1 for x86; and YellowDog 1.2 for PowerPC. MontaVista's decision to support a PowerPC host is admirable, but I'm sure Debian users will be disappointed to find that only RPM-based distributions are listed.

My own host platform happens to be an x86 PC running Red Hat 7.1 — not a currently supported platform. This situation caused some problems . . .

• First, the installation process installs RPM files specific to the version of RPM installed on the host. The installation script (hhl-host-install) attempts to determine the version of RPM in part by determining the distribution used; it does this by looking for and parsing the /etc/*-release file. In the case of a Red Hat distribution, it parses the /etc/redhat-release file, looking either for 6.2 or 7.0, the only supported platforms. For Red Hat 7.1, it fails to find either, and attempts to install the wrong RPMs. The workaround is simply to edit /etc/redhat-release to fool hhl-host-install into believing the host is Red Hat 7.0. Since the 7.0 and 7.1 RPM programs are compatible for purposes of basic Hard Hat installation, the process then runs smoothly.

• By default, Hard Hat installs at /opt. As my disk partition containing /opt was nearly full, I attempted to install it on another partition using the '–hhldir' option to hhl-host-install. This operation failed; under Red Hat 7.1 installation must be at /opt. MontaVista reports that this failure is because of RPM incompatibilities; they are working on a solution. I worked around the problem by simply mounting the partition I wanted to use at /opt and installing Hard Hat at the default location.

Keep in mind that the installation problems I encountered were all due to my using an unsupported host distribution, albeit one (Red Hat 7.1) that is by now widely used.

You can choose either installation for cross-hosted development (the most common case) or installation for self-hosted development.

Self-hosted development

Self-hosting can be very useful for offline development — you can do the bulk of your software development on a desktop or laptop; you then only need the cross-development environment when interfacing to hardware specific to your target hardware. But Hard Hat's self-hosting model is not very useful. Essentially the self-hosted distribution is used as a substitute for a full desktop distribution. You install the self-hosted distribution onto your computer's hard drive, replacing any desktop operating system it previously had. Your development and operating environment is then limited to whatever facilities are provided by Hard Hat.

The usefulness of such a model is unclear. One could conceive of a target device with resources sufficient to support a development effort, or one to which resources could be temporarily added for such a purpose. For example, a Pentium-based SBC could be enhanced with CD-ROM, floppy, and hard drives; and perhaps with extra memory.

Realistic self-hosted development would presumably proceed as follows . . .

• Add the hardware resources needed for development on the SBC.

• Install a full self-hosted development environment.

• Become accustomed to this environment. It is likely to be missing tools you rely on from your normal desktop environment. Either install these tools manually one by one as you discover them missing, or just learn to live with their absence.

• Develop your application. This may be somewhat frustrating if your target has a Pentium 166 or 266 and you are expecting compiles to proceed as on your much faster desktop machine.

• Strip the system back down to its intended target configuration and size. The tools you added earlier are likely to have expanded the system beyond its target size.

• Deploy.

Not to belabor the point, but this is simply not how embedded software development proceeds.

A useful self-hosted development model would maintain the user's desktop environment, deploying the target to a separate partition or its own directory, and allowing the user to boot that target image for testing. That way, the user could perform the bulk of his or her development, and determine roughly what size the target image would have, on a desktop computer without the need for the target hardware.

One could probably configure such a development environment within the Hard Hat concept of self-hosting by setting up and booting from a Hard Hat partition on a desktop system's hard drive and setting up the proper links and environment variables to use the tools on the desktop system's distribution partition. However, such an effort would likely be frustrating to a beginner.

— Continued —

---

Story navigation . . .

• Part 1: First impressions
  
• Part 2: Getting started
  
• Part 3: Cross-development
  
• Part 4: GUI-based Target Configuration Tool
  
• Part 5: Other observations
  
• Part 6: Overall assessment

 
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.