The PowerQuicc III: Building A Solution
It was time to go back to the Web to find specific commercial board support for the PowerQuicc III. After some searching, it turned out that both TimeSys and MontaVista had public board support for the ADS evaluation platform. These provided alternative commercial solutions in addition to the public kernels from the rsync site. There are five basic steps to follow to get a final build solution for the ads8560 platform.
Step 1: Installation
One of the biggest advantages of working with the ELDK tools is the ease of installation. Simply load the CD and install using the install.sh script. This script deals with every nuance of the delivered RPM packages without requiring the user to be an RPM expert. Many solutions don't provide this level of control. Instead, they require that you extract RPMs, which unnecessarily complicates the whole process. If the user is installing an entire architecture family, such as the complete ELDK for PPC, expect the install process to take a bit of time, especially on older hardware.
In a similar fashion, the MontaVista Preview Kit with the LSP for the ads8560 board also has a script that allows for straightforward installation. The Preview Kit typically installs into the /opt directory within a few minutes. After some searching of the /opt/montavista directory, the user will find the LSP directory containing the actual Linux kernel-in this case, a 2.4.20 version.
Step 2: Configuration
The build process involved using the "make menuconfig" approach. Other developers use "make oldconfig" or "make xconfig" instead, as a matter of personal preference. The arch/ppc/configs directory contains default configuration files for specific hardware platforms. Here, the MontaVista LSP contained a file called mpc8560_ads_defconfig, which was copied to the kernel directory and renamed to .config. The actual configuration process is immediate when using a preexisting script as in this case. Otherwise, in many cases, selecting the appropriate selections for the kernel can take a few hours. Figure 1 shows an example of the menuconfig approach.
Step 3: Building
Usually the first step in creating a build solution for Linux is getting the basic command line build working with the particular tools solution (ELDK 3.1.1) and the particular Linux kernel tree you are using. In this case, it's the MontaVista Linux Support Package (LSP) for the ads8560 board. The two goals of this process are to first create a working "make clean," "make dep," "make" sequence that produces a final executable, and then to work these into an appropriate build script.
When building for embedded or cross-development targets such as PowerPC platforms, the user usually sets the ARCH and CROSS_COMPILE variables in the kernel Makefile. In this example, the Makefile was modified to add the lines "ARCH := ppc" and "CROSS_COMPILE = ppc_85xx-," replacing the default lines. Doing a typical Linux kernel build completely from scratch has been known to take 30 minutes or more. Time depends heavily on the speed of your desktop hardware and any other applications that may be running at the same time.
Step 4: Scripting
Once you have a valid build sequence, it's easiest to create appropriate Linux build scripts for the specific Linux kernel and tools combinations being used. These are especially useful when mixing GNU tools support from one vendor with board support from a different vendor. Figure 2 lists a typical build script. It has always mystified me why such build scripts aren't a standard part of every Linux distribution. Using appropriate build scripts, both the MontaVista 2.4.20 ADS and the TimeSys 2.6.4 ADS kernels were built using the ELDK 3.1.1 GNU tools. Builds were then performed for the rsync 2.4 and 2.6 kernels.
Step 5: Testing
Extensive testing with real hardware can commence. This is a huge area best covered in a separate discussion, but here are the basics. Now that a system has been created with an initial board boot-up solution (UBoot, Board Firmware), it is time to build the first typical Linux kernel. The Linux kernel requires a UNIX-like root file structure to run properly. This step can go in one of two ways. The first employs an NFS-mounted root file system. The ELDK tools already provide this type of file system via the /eldk311/ppc_85xx directory for PowerQuicc III hardware. The NFS-enabled Linux kernel is most commonly used as a downloadable image for application development.
In many embedded scenarios, however, the NFS-mounted kernel isn't the right choice. In these cases, the kernel must be configured to utilize an onboard RAMdisk image. The RAMdisk image, a separately compiled root file system, provides smaller Linux components in a root file system image that's suitable for burning into a flash device. RAMdisk images can vary wildly in size depending on which components are built in. Pre-built RAMdisk images are publicly available from multiple sources, or you can build your own. Combining the RAMdisk image in flash, the RAMdisk-enabled Linux kernel (which also can be stored in flash), and the boot-up solution in flash, you now have a final embedded Linux solution.
The PowerQuicc III: Bundling The Solution
In our organization, we provide an Eclipse-based Linux development environment complete with a supported Linux software development kit (SDK) (Fig. 3). We have such a strong preference for the ELDK solution in part because the GNU tools and full Linux distribution all sit in a single directory hierarchy that's easily "tar'ed, zipped, and shipped."
We bundled the Linux 2.4.30-pre1 kernel from rsync with the ELDK 3.1.1 tools from DENX to create a final solution for users of the ads8560 board. Preferring a single directory structure for our SDKs, we moved the 2.4.30-pre1 kernel directory under the "ads8560_sdk/eldk3.1.1/ppc_85xx/usr/src" directory, effectively merging the two directory structures for tools and kernels with board support. The UBoot solution and the RAMdisk image also are provided within the same usr/src directory structure. At this point, we're free to tar the entire directory structure, gzip it, and manufacture the SDK for shipping. While merging the two directories isn't strictly necessary, it presents a simpler structure to the end user.
The Eclipse framework lets users add their own customer scripts into the environment via the external tools menu pull-down (Fig. 4). Our initial product integration using this capability is shown with a completed build in Figure 5.
This article has endeavored to cover a good deal of ground on how to pull together a Linux distribution from the many different possible sources and vendors. It also has called out many of the potential pitfalls that await the unprepared or unwary developer. Ultimately, when the development team has made their respective choices and engineering tradeoffs necessary to settle on a particular solution for their development needs, though, one outstanding question remains: Whose Linux is it anyway? Regardless of whether you're using a proprietary or fully open solution, and regardless of any real-time extensions you may choose, the answer is obvious. It's your Linux!