Operating systems porting


Porting is the process of adapting a software so that an executable program can be created for a computing environment that is different from the one for which it was originally created.

What is Porting?

The process of adapting SW so that an executable program can be created for a computing environment that is different from the one for which it was originally created.

Figure 1: Windows and Mac are 2 different environments. Porting is needed if the software is running on one of them and there is a need to make it run on the other environment.

In PC world, porting is not rare because:

· x86 is the dominant CPU architecture

· Windows or UNIX flavors are the dominant operating systems.

· International standards like ISO and POSIX facilitate seamless running of the software.

In embedded world, porting is a significant issue. This is natural because embedded systems are custom by nature.

Layered Architecture and Porting

Any embedded system can be seen as a set of layers interacting together from the application layer down to the hardware layer passing by middleware or libraries, operating system if exists, and finally the device drivers layer.

To have a solid layered architecture, it should be strict. In other words, a layer can only communicate with the layer just beneath through function calls or with the upper layer just above it through callbacks. This is necessary to increase the cohesion and decrease the coupling in our system design though it might impact performance.

To understand the relation between the layered architecture and porting, let’s imagine that we suddenly changed the operating system layer. Consequently, the middleware or libraries layer has to be changed to adapt to the change. This is called middleware or libraries porting. By having a complete look on figure 2; it is easy to conclude the other types of porting.

Figure 2: Layered architecture and different types of porting in embedded systems

It is worth noting that as the lower the layer to be changed, the harder the porting process.

OS Porting

OS porting is the most difficult type of porting, as it requires solid knowledge of the OS internals as well as the subtleties of the hardware.

Moreover, there are different types of OS porting.

Figure 3: Type of OS porting

Architecture OS porting is the most difficult type of OS porting. Because the main task of the OS is to support multitasking, architecture OS porting is concerned with modifying the dispatcher code to support the context switching specific to that architecture. The issue becomes more complicated of the OS is process based as the dispatcher code should handle the memory management unit issues as well.

Moreover, architecture OS porting must take into account the exceptions handling issues like nesting and OS preemption that is specific to that architecture.

Architecture OS porting becomes a nightmare when knowing that the OS’s kernel is microkernel and not a monolithic one.

The other type of OS porting is called board porting. After the OS has been ported to the new architecture, it should understand the on-chip and off-chip peripherals attached my main CPU. In other words, develop the drivers for the OS to understand the devices connected to my board.

Board OS porting has two subtypes; basic board porting and board support package.

The basic board porting scope is to verify the proper board operation with the minimal set of peripherals. The minimal set can be the memory devices, the interrupt controller unit, the clocking circuits, dedicated hardware timer, and an IO device like UART.

The board support package scope is developing all the device drivers for my board as well as the bootloader. The minimal BSP can be considered the basic board porting.

Porting Rules

The first rule in porting is no rule. After reading the porting guide of your OS and referring to your architecture documentation, in most of the cases porting engineers do choices that violate what is in the OS porting guide.

As a case study, I advice taking uCOS-II developed by Micrium incorporation as an example and try porting it over x86 architecture as well as ARM cortex-M architecture.

To get started with that exercise, please refer to porting uCOS-II presentation and to ports on Micrium website.

Amr Ali
Embedded Systems Engineer

Related posts:


Post a Comment

Your email is never published nor shared. Required fields are marked *


Facebook Comments