Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

• GDB on the host typically uses IP connections via Ethernet to send and receive commands to gdbserver running on the target. The GDB remote serial protocol is used between GDB and gdbserver.

• GDB can halt on shared library events and can automatically load shared library symbols when available. Your toolchain should be configured for the default paths on your cross-development system. Alternatively, you can use GDB commands to set the search paths for shared library objects.

• GDB can be used to debug multiple independent processes via multiple concurrent GDB sessions.

• GDB can be configured to follow a forked process on a fork() system call. Its default mode is to continue to debug the parentthat is, the caller of fork().

• GDB has features to facilitate debugging multithreaded applications written to POSIX thread APIs. The current default Linux thread library is the Native Posix Threads Library (NPTL).

• GDB supports attaching to and detaching from an already running process.

GDB: The GNU Project Debugger

Online Documentation

http://sourceware.org/gdb/onlinedocs/

GDB Pocket Reference

Arnold Robbins

O'Reilly Media, 2005

It is not difficult to port Linux to a new hardware platform. The Linux source tree contains ports for numerous boards spanning more than 20 architectures and many more individual processors. Knowing where to start is often the hardest part.

This chapter covers the basics of porting Linux to a custom board providing support for basic Ethernet and serial console operation. We examine the organization of the Linux source code from an architectural and platform perspective. We then delve into the early kernel initialization code to understand the mechanisms provided for platform initialization. Finally, we look at a typical porting effort to a custom PowerPC hardware platform.

Not too long ago, there were numerous homes [106] By "homes," we mean a public source code repository, such as a web server on the Internet. 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.

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 architecture branch to facilitate our discussions.

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.