Linux Kernel Porting, Jargon Buster

There are various different computer architectures that are available today. For example, desktop computers are based on the x86 architecture, and most mobile phones are based on the ARM architecture. Each architecture has its own set of machine instructions, its own way of dealing with interrupts and its own way of interacting with memory.

When we port the kernel to a new architecture, fundamental changes have to be made to the core parts of the kernel, right from the boot process, to how system calls are invoked. This makes it the most difficult type of porting activity, since developers need a deep understanding of the kernel and should be able to figure out the right-way to implement the core OS features in the new architecture.

Within a single architecture like ARM, there are many vendors that provide System-on-Chips AKA SoCs. An ARM SoC has an ARM processor core and peripherals like UART, PWM, ADC, USB Interface, etc. all on a single chip. SoCs make designing embedded systems, drastically simple, because most of peripherals required to build the system is within a single chip. Example of ARM SoCs include Atmel SAMA5D3, TI OMAP4430 and Freescale i.MX535.

Porting the kernel to a new SoC, will involve adding new drivers for each of the peripheral that is present in the SoC. This will include writing drivers for system peripherals that provide the low level infrastructure for other peripherals, like the interrupt controller, the clock controllers, the GPIO and pin controller, the voltage regulator, etc.

Developing the drivers for the system peripherals and other controllers is a complex task. It requires a good understanding of the various subsystems, like the interrupt handling subsystem, the clock subsystem, the GPIO and pin controller subsystem, etc.

The SoC can be utilized in several different boards. In each board, the same SoC, can be used in may different ways. They might differ in the set of peripherals utilized, the size of external RAM connected to the SoC, the choice of secondary storage, the crystal frequency used for generating the clock, etc.

For each board, information is required in the kernel to support that board. Earlier, this information used to be represented using board specific kernel data structures and kernel code. These data structures were generally used by drivers to know board specific details of a peripheral. For example, the MMC Controller driver requires the use of two GPIO inputs to detect the presence of a card (Card Detect, CD) and to determine the write protect status of the card (Write Protect, WP). The various signals required by the MMC is shown in the following diagram.

Which GPIOs are used for this purpose is board specific. The board specific code, encodes this information in a structure and passes it to the MMC Controller driver.

These days, the Linux kernel represents this board specific information, using the "device tree". The device tree is a data structure for describing hardware. A board specific device tree, describes the hardware present on a board. The device tree is passed to the kernel as a separate file. The device drivers query the device tree to determine for example, which GPIOs are used for Card Detect and Write Protect. A device tree fragment that describes this information is shown below.

This greatly simplifies the task of modifying the kernel to support a new board. Since only a new device tree representation has to be written for the board. Nevertheless, boards with on-board peripherals not supported by kernel, might still require development of kernel code / drivers for these peripherals.