Linux Kernel Porting, Jargon Buster

This article is about Linux kernel porting, and other related terms like flashing and bring-up. The terms are generally used incorrectly. Through this article I hope to give clear definition of each term and how they relate to one another.

What is Porting?

The Linux kernel being open source, has enabled people to modify it, to work with a variety of hardware. Today, Linux runs on tiny watches to large supercomputers. When developers modify the kernel to work on a new hardware, the kernel is said to be ported to that hardware. And the process of changing the kernel, is called porting.

There are various types of porting, depending on the level of changes being made to the kernel.

  1. Architecture Port

  2. SoC Port

  3. Board Port

Architecture Port

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.

SoC Port

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.

Board Port

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.

http://www.zilogic.com/static/images/mmc-gpio.png

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.

mmc@0x23F00000 {
    cd-gpios = <&gpio 5>;
    wp-gpios = <&gpio 6>;
};

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.

Porting vs Flashing

The process of writing the kernel image and filesystem into the target, is called Flashing. Many people use the word Porting, when they really mean Flashing. Porting involves an iteration through

  1. Modifying the code for the particular hardware

  2. Compiling it for the hardware

  3. Flashing the image on the target hardware

  4. Testing the changes made to the software

But, the modification of the code to support a particular hardware is a key ingredient of the porting process. Hence, if no changes are involved and the developer only compiles and flashes the kernel image, that would be considered Flashing.

Porting vs Bring-up

When a SoC / board is designed and is manufactured for the first time, there are lot of variables, while trying to get the system to work.

  1. The hardware could have design defects. For example, the hardware designer did not add a required wire between two chips or hardware blocks.

  2. The hardware could have manufacturing defects. For example, even though the schematics says that there should be wire between two chips, due to manufacturing defects and soldering defects there could be open circuit on the wire.

  3. The software could have bugs, since the modifications made to the software for the hardware, has not been tested so-far, as this is the first time this particular hardware has ever been manufactured.

Getting the hardware and software to a working state under these variables, is what constitutes hardware bring-up. Fixes to issues encountered could range from simple workaround in the software, to reworking the hardware by adding jumpers. Board bring-up of complex hardware, can be really hard and the time frame for such activity can be extremely unpredictable.

So hardware bring-up will involve testing of the software modification made for the hardware. A set diagram showing how porting and bring-up relate is provided below.

http://www.zilogic.com/static/images/porting-flashing-bringup.png

Concluding Remarks

The terms Porting, Flashing and Bring-up are inter-related, in certain ways. This has resulted in the terms being mixed-up and being used incorrectly. Hope this article has helped people better understand each term, and how they relate to each other.