Custom Linux Kernel Development

TODO: {{#todo:InProgress|Travis Stratman|oe 5,TS,InProgress}}

The ability to easily customize and expand any portion of the kernel is a feature of Linux that makes it very well suited for embedded systems development. In the embedded environment, specialized hardware, protocols, and systems may require a look into the kernel internals, custom configuration, feature additions, or driver development. This article aims to provide information on the most common kernel development tasks for EMAC OE Linux systems. In addition, the reader is pointed to sources for kernel development resources.

Prerequisites

This article assumes some basic familiarity with Linux and C programming competency. Before continuing, make sure that git is installed on your development machine, and review the Building the Linux Kernel document.

Background

Maybe some more here about the technical design of the kernel and very brief history... monolithic kernel, loadable modules, etc. For now just see wikipedia http://en.wikipedia.org/wiki/Linux_kernel

The Kernel Source

Source code for EMAC kernels is provided through our Git server. Refer to the documentation for your system to determine the correct source to use.

Clone the Git Repository

To clone the git repository over anonymous HTTP, run the following commands:

developer@ldc:~$ git clone http://git.emacinc.com/public/source/linux-2.6.30-at91.git

Once the command has completed, the entire source should be contained in the linux-2.6.30-at91 directory. The master branch will be checked out automatically. Because EMAC uses the master branch for all releases, this is the correct branch to use, but other branches or tags may be checked out if directed or required.

Kernel Source Structure

Within the kernel source tree that was downloaded, you will see several directories. Table 1 gives a brief description of each of these directories.

Directory name	Description
arch	Architecture-specific kernel code with subdirectories for each architecture
block	Block device driver code
crypto	Encryption support algorithms
Documentation	Text documentation files on the kernel and APIs
drivers	Device driver code, with a subdirectory structure for each device type
firmware	Code for building firmware required to communicate with devices
fs	File systems code
include	Include (header) files required to build the kernel code
init	Kernel initialization code
ipc	Interprocess communications code
kernel	Main internal kernel code
lib	Library code
mm	Memory management code
net	Kernel networking code
samples	Code examples and drivers that have not been fully developed
scripts	Various scripts used for the configuration and build process as well as standalone utility scripts
security	Kernel security support
sound	Sound and audio driver code
usr	Code used during kernel image creation
virt	Virtualization support code

These directories will be referred to as needed in this document.

Configuration

The kernel uses a configuration system that specifies how every aspect of the kernel is built.

Configuration Structure

The kernel configuration is generated based on selections by the user combined with dependency information built into the Kconfig structure. You will find a file named Kconfig in most source directories within the kernel. These files follow the language described in Documentation/kbuild/kconfig-language.txt and control the structure and operation of the kernel configuration utility.

The current kernel configuration is stored in a file named .config in the top level of the kernel source tree. This file is read and updated by the configuration utility and is used by the make system during the build process. The first step in configuring the kernel often involves initializing this file with a default configuration set up with sane values for the target platform. These default configuration files are stored under the arch directory. For example, arch/arm/configs/.

In this example, copy the arch/arm/configs/som9g45-som210_defconfig file to the top level of the kernel source as .config:

developer@ldc:~$ cp arch/arm/configs/som9g45-som210_defconfig .config

This is the default configuration file for the EMAC SoM-9G45 module using an SoM-210ES carrier board.

The configuration file defines all CONFIG values that are set, either y (yes), m (module), a numeric value, or a string value. Options not configured are entered into the file as a comment with the option followed by the words "is not set." An example of each of these formats is shown below:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30
# Tue Jan 10 17:42:58 2012
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
...
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
...
CONFIG_INIT_ENV_ARG_LIMIT=32
...
CONFIG_SDIO_UART=m

Configuring the Kernel

The kernel supports several methods of generating configuration values including command line utilities, a menu-based utility, a Qt-based utility, and a GTK+-based utility. These utilities are instantiated as make targets. The menu-based utility, invoked by the menuconfig command is the only option supported by the EMAC Linux kernel build script. See here for more information on how to initiate the configuration process using the EMAC Linux kernel build script.

Menuconfig

The top-level interface to the kernel menuconfig utility is shown in Figure 1. Note that the navigation keys and legend are shown at the top of the page.

Figure 1: Linux Kernel Menuconfig Main Page

Any menu item with a ---> will lead to a submenu with further options. For example, to set the EMAC carrier board used with this SoM, you would use the arrow keys to highlight System Type and press Enter to select. From this menu, select Atmel AT91 System-on-Chip followed by EMAC Carrier Board Selection. This will initiate a menu allowing a single selection with all of the carrier boards supported by the currently selected SoM module. If, for example, you wanted to target the SoM-200ES carrier board, you could highlight SOM-200ES Carrier Support and press the space bar or Enter to select.

Once all desired changes have been made, select Exit and press enter from the main menu. You will be prompted to save the kernel configuration as shown in Figure 2.

Figure 2: Linux Kernel Menuconfig Save Confirmation

If configuration options are the only customization required for your project, you may continue by building the kernel. If only loadable module options were changed from the original configuration that your running kernel was built with, you will only need to load the modules onto the target system as described here. If other built-in options were modified, you will need to reload the kernel image as well, which requires a different procedure depending on the bootloader. More here links for different bootloaders

Adding Support for a New Carrier Board

One common kernel development task working with EMAC systems is adding support for a new custom carrier board for use with an EMAC SoM. In general, the procedure for this task is to use one of the existing EMAC carrier board support files as a base and modify as needed to support the custom hardware. Additions to the Makefiles and Kconfig are also generally required to add new selections to the kernel configuration and build system. This section covers an example of the work required for this using the SoM-9G45 module as an example.

Machine-Specific Support Files

Board-level support files are found under the machine-specific directories within the kernel structure for ARM devices. For the Atmel AT91-based devices, this is found under arch/arm/mach-at91. Within this directory, you will see some CPU-specific support and includes, as well as a collection of files prefixed with board-. These files contain configuration and initialization code to support a specific board -- only one of which may be included in a single kernel binary.

The board support file for the SoM9G45 is board-som9m10g45.c. Looking at this file, you will see that it contains code for devices inherent to the module, such as the flash, LCD, Ethernet PHY, micro-SD (MMC), and others. You will also notice references to the cspec ("carrier specification") structure. This structure is defined by code in the carrier board file and determines which devices are enabled and how they are configured to match the features of the target carrier board.

For example, in the som_board_init() function, SPI support is configured with the following lines:

/* SPI */
at91_add_device_spi(som_spi_devices, ARRAY_SIZE(som_spi_devices));

if (cspec.use_periph & CARRIER_USES_SPI)
	at91_add_device_spi(cspec.carrier_spi_info, cspec.carrier_spi_cnt);

The first call to at91_add_device_spi() adds devices present on the SoM itself, while the next lines check to see if the carrier board specification indicates that SPI is utilized, and if so the devices in the carrier board spi configuration are added. The carrier support functions and definitions are included through arch/arm/mach-at91/include/mach/emac-carrier.h.

Carrier Board-Specific Support

The emac-carrier directory contains code and configuration specifically for support of EMAC carrier boards. This code is used to generate the carrier specification values used in the board-som9m10g45.c file as shown above. The Kconfig file in the emac-carrier directory is sourced from the mach-at91/Kconfig file and provides selections for all available carrier boards. A snippet of the emac-carrier/Kconfig file is shown below.

if MACH_SOM9M10G45

choice
	prompt "EMAC Carrier Board Selection"
....
config SOM200_CARRIER
	bool "SOM-200ES Carrier Support"

config SOM210_CARRIER
	bool "SOM-210ES (PPC-E4) Carrier Support"

config SOM212_CARRIER
	bool "SOM-212ES Carrier Support"

config SOM250_CARRIER
	bool "SOM-250ES (PPC-E10/PPC-E7+) Carrier Support"

endchoice

This generates the selection menu discussed in the Menuconfig section. If "SOM-210ES (PPC-E4) Carrier Support" is selected in the menu, the variable CONFIG_SOM210_CARRIER will be defined. Looking at emac-carrier/Makefile, you will see entries for each carrier board as well as other related options. For example, the line below specifies that board-som210.c will be compiled and included in the image if the SOM-210ES carrier support option is selected.

obj-$(CONFIG_SOM210_CARRIER)	+= board-som210.o

Taking SOM-210ES as an example, look at the board-som210.c. You will see a good portion of software that is very similar to the full board support files in the mach-at91 directory, since this file defines all peripheral support required by the carrier board hardware not included in the base code for the SoM itself. At the bottom of the file, you will find the carrier_init() function, which is called from the SoM initialization code and sets up the carrier_spec struct. This function is shown below for review:

int __init carrier_init(struct carrier_spec *spec)
{
	spec->use_periph  = CARRIER_USES_USBH | CARRIER_USES_MCI | \
			    CARRIER_USES_TSADCC | CARRIER_USES_PWM | \
			    CARRIER_USES_LCD | CARRIER_USES_SPI | \ 
			    CARRIER_USES_I2C0;

	spec->carrier_map_io = carrier_map_io;
	spec->carrier_boardspec = carrier_device_boardspec;
	spec->carrier_spi_info = carrier_spi_devices;
	spec->carrier_spi_cnt = ARRAY_SIZE(carrier_spi_devices);

	return 0;

}

Note that some of the carrier_spec parameters are function pointers, such as spec->carrier_map_io and spec->carrier_boardspec.

Example New Carrier Board Support File

Suppose that support for a new carrier board is required and utilizes hardware very similar to the SoM-210ES.

Create new SoM carrier file using this as demo.

Driver Development

Basic info on driver structure here.

Licensing

It is important to note that all code built-in to the kernel automatically fall under the the GPLv2 license and must use an Open Source license compatible with the terms of the GPL. For loadable kernel modules, there is controversy over whether modules are derived works of the kernel. While proprietary and other non-GPL-compatible modules are generally permitted, several restrictions apply: The "taint" flag will be set on the kernel as soon as the module is loaded, and certain symbols are only available to modules marked with a GPL-compatible license.

EMAC recommends that you seek legal advice if you are unsure of the license requirements for your software.

See the following resources for more information:

• Open Source Licensing
• Linux Kernel COPYING File
• | TLDP.org LKM Copyright Article

Where to go for Additional Information

There is an abundance of information available both online and in-print on the topic of Linux kernel development. Some of these resources are discussed below.

Kernel.org

Kernel.org is the site hosting the Linux kernel. Source code, news, links, and other helpful information related to the Linux kernel can be found on this site.

Linux Device Drivers, Third Edition (LDD3)

This book is available online in free PDF form through the LWN.net site. It is also available in-print through O'Reilly. LDD3 covers most of the topics required for Linux kernel development and includes examples. Note that some of the APIs covered have changed since 2.6.10 when the book was written so adaptation may be required to use the example code.

Mailing Lists

There are many very active mailing lists (see http://vger.kernel.org/vger-lists.html) that can be used to ask questions or search through archives for solutions. The archive of the Linux Kernel mailing list is available at LKML.org and archives to other lists can be found through a web search as well as links noted in the list here.

Linux Kernel in a Nutshell

This book is written by Greg Kroah-Hartman, one of the primary developers and maintainers of the kernel and covers the process and tools for building, configuration, and installation of the Linux kernel. It is available for free through the authors site in electronic format or in-print through O'Reilly.

EMAC Support

EMAC provides custom Linux kernel development and kernel development support for EMAC customers on a contractual basis. Contact EMAC Support for more information.