Not too long ago, there were numerous homes[106] for the various versions of Linux. There was a dedicated place for the PowerPC version of Linux, one for the ARM version, and so on. This wasn't necessarily by design, but by necessity. It took time to merge the various architecture infrastructure and features into the mainline kernel, and having a separate source tree meant quicker access to the latest features in a given architecture.
The kernel developers have gone to great lengths to unify the Linux kernel source code to bring together the disparate architectures under one common source tree. With few exceptions, this is the case today with the Linux 2.6 source. It is possible to download and compile working kernels for a variety of processors and industry- standard reference boards directly from www.kernel.org.
16.1.1. The Architecture Branch
In Chapter 4, 'The Linux Kernel: A Different Perspective,' we introduced the overall structure of the Linux kernel source tree. We spend the majority of this chapter examining the architecture-specific branch of the Linux kernel sources. Listing 16-1 shows the contents of .../arch from a recent kernel snapshot. As we pointed out in Chapter 4, the .../arch subdirectory is the second largest in terms of size, and in a recent Linux release, the largest in terms of file count (excluding the .../include directory). Only the .../drivers subdirectory is larger in size.
Listing 16-1. Linux Kernel .../arch Directory Listing
[chris@pluto linux]$ ls ./arch
alpha cris i386 m68k parisc s390 sparc v850
arm frv ia64 m68knommu ppc sh sparc64 x86_64
arm26 h8300 m32r mips ppc64 sh64 um xtensa
From this listing, you can see support for 24 separate architectures within the Linux kernel. We refer to each as an
Each architecture branch has some common components. For example, each top-level architecture branch contains a Kconfig file. You will recall from Chapter 4 that Kconfig drives the kernel configuration utility. Of course, each top-level architecture branch also has a corresponding makefile. All the top-level architectures contain a kernel subdirectory because a number of kernel features are architecture dependent. All but two contain an mm subdirectory. This is where the architecture-dependent memory management code is found.
Many top-level architecture branches contain a boot subdirectory, which is used to build (through its own makefile) a specific bootable target for that architecture. Many also contain mach-* subdirectories. These are used to hold code for specific machines or hardware platforms. Another subdirectory that appears frequently in the architecture branch is configs. This subdirectory exists for many of the more popular architectures and contains default configurations for each supported hardware platform.
Throughout the rest of this chapter, we focus our discussion and examples on the PowerPC architecture. It is one of the most popular, with support for many processors and boards. Listing 16-2 shows the contents of the configs directory for the .../arch/ppc PowerPC branch of a recent Linux kernel release.
Listing 16-2. PowerPC configs Directory Contents
[chris@pluto linux]$ ls ./arch/ppc/configs/
ads8272_defconfig IVMS8_defconfig prpmc750_defconfig
apus_defconfig katana_defconfig prpmc800_defconfig
bamboo_defconfig lite5200_defconfig radstone_defconfig
bseip_defconfig lopec_defconfig redwood5_defconfig
bubinga_defconfig luan_defconfig redwood6_defconfig
chestnut_defconfig mbx_defconfig rpx8260_defconfig
common_defconfig mpc834x_sys_defconfig rpxcllf_defconfig
cpci405_defconfig mpc8540_ads_defconfig rpxlite_defconfig
cpci690_defconfig mpc8548_cds_defconfig sandpoint_defconfig
ebony_defconfig mpc8555_cds_defconfig spruce_defconfig
ep405_defconfig mpc8560_ads_defconfig stx_gp3_defconfig
est8260_defconfig mpc86x_ads_defconfig sycamore_defconfig
ev64260_defconfig mpc885ads_defconfig TQM823L_defconfig
ev64360_defconfig mvme5100_defconfig TQM8260_defconfig
FADS_defconfig ocotea_defconfig TQM850L_defconfig
gemini_defconfig pmac_defconfig TQM860L_defconfig
hdpu_defconfig power3_defconfig walnut_defconfig
ibmchrp_defconfig pplus_defconfig
Each one of these entries in the configs directory of the PowerPC architecture branch represents a specific port to a hardware platform. For example, walnut_defconfig defines the default configuration for the AMCC Walnut PPC405 evaluation platform. The mpc8540_ads_defconfig file represents the default configuration for the Freescale MPC8540 ADS evaluation board. As described in Chapter 4, to build a kernel for these reference platforms you first configure your kernel source tree with these configuration defaults, as follows:
$ make ARCH=ppc CROSS_COMPILE=ppc_85xx- mpc8540_ads_defconfig
This invocation of make (from the top-level Linux directory) configures the kernel source tree with a default configuration for the Freescale MPC8540 ADS evaluation board.
One aspect of the Linux kernel source tree that has not achieved significant unification is the way in which each architecture handles platform-specific files. In the PowerPC branch, you find a platforms directory that contains platform-specific code. Looking through this directory, you will see many source files named after the respective hardware platform. There are also a few subdirectories under .../arch/ppc/platforms for specific PowerPC variants.
In contrast, the ARM branch contains a series of mach-* directories, each representing a specific hardware platform, while the MIPS branch has a set of subdirectories named for a specific platform.
16.2. Custom Linux for Your Board
When we ported U-Boot to a new hardware platform in Chapter 7, 'Bootloaders,' we found the configuration that most closely matched our new board and borrowed from that port. We use a similar technique to port Linux to our new board. We assume that the chosen CPU is already supported in the kernel. Porting to a new CPU is significantly more challenging and beyond the scope of this book.
We have chosen to port Linux to a custom controller board based on the Freescale MPC5200 32-bit embedded PowerPC processor. Looking through the default configurations from a recent Linux release (as depicted in Listing 16-2), we find one that contains the MPC5200 CPU. Because it appears that this is the only configuration that supports this processor, we use it as our baseline.
The hardware platform that we use for this exercise was supplied courtesy of United Electronic Industries. The board is called the PowerDNA Controller. It has a simple block diagram, containing onboard Flash memory, dynamic RAM, a serial port, and a variety of I/O devices, mostly integrated into the MPC5200 processor. Figure 16 -1 is the block diagram of the PowerDNA Controller.
Figure 16-1. UEI PowerDNA Controller board
