Linux Porting

Linux Porting
&
Linux Support Package
© 2010-14 SysPlay Workshops <workshop@sysplay.in>
All Rights Reserved.

What to Expect?
Kernel Basics for Linux Porting
W's of Linux Porting
W's of Linux Support Package (LSP)
Architecture of LSPs
Browse & Understand the LSPs
LSP & Board Bringup Connections
© 2010-14 SysPlay Workshops <workshop@sysplay.in> 2

Some Basics
For
Understanding Linux Porting

Kernel Items to Consider
Version
Major
Minor
Sequence
Extra version
/proc/version
Source Repositories & Mailing Lists
Architecture Specific
Architecture Merging Efforts

Kernel Configuration (Detailed)
Changing the .config by hand
Preparing & Using a default config
Example: arch/arm/configs/omap3evm
Other Configs: rand, allmod, allyes, allno
Adding an Entry
Change in Kconfig
Change in Makefile
Let's have a demonstration
The autoconf.h

Kernel Image Components
Observe the Makefile &/or vmlinux build with V=1
Objects
arch/<arch>/kernel/head.o
Kernel Architecture specific startup code
arch/<arch>/kernel/init-task.o
Initial thread & task structs required by Kernel
init/built-in.o
Main kernel initialization code
…
Linker script
arch/<arch>/kernel/vmlinux.lds
Kernel Bootstrap Loader
Initialize Processor's internal caches and C runtime environment (head*.o)
Decompression & re-location (misc.o)
Processor-specific initialization, e.g. endian related (*endian.o)

Kernel Initialization (Detailed)
Kernel Entry Point
arch/<arch>/kernel/head*.o
Kernel Startup
init/main.c → start_kernel();
Browse the code
Architecture Setup
Command Line Processing & __setup macro(arg, f)
Subsystem Initializations & Initcalls (for memory free up)
Kernel init Thread → init process
Idle Process

Let's get down to the Source Code

Let's Check
Where are the following things done?
MMU switching ON
Starting of kernel
Mounting of init ramdisk and root filesystem
board_init invocation
Where is the default command line setup?
'Booting Kernel' message
Machine Id verification
Command Line parsing
start_kernel location

Linux Porting

What is Porting?
“To Port” is “To Carry”
Adapting to the Environment
That it was not Designed for
And by “(Embedded) Linux Porting” we mean
Adapting Linux to work on an Embedded Platform
So, what does it take to port Linux
At high level, the 5's of Embedded Systems
And at kernel level, the 5 M's of OS

5 M's of OS (Revisited)
Architecture Porting
Processor Management
Memory Management
Board Porting
I/O Management
Storage Management
Network Management

Linux Porting
Architecture Porting is a subject in itself
Would talk in a separate session
Board Porting
Board-specific Initialization Code
And majorly Drivers Porting
So, part of the Kernel Space
Two categories of Drivers
Standard Device Drivers
Part of the Kernel
Or, Needs to be done as for writing the standard Linux Drivers
At the standard directory locations
Custom Device / Interface Drivers
Board-specific Custom Code required
Needs to be specifically brought-in with the Kernel

What is Linux Support Package?
Collection of this board specific
Initialization & Custom Code is referred as
Board Support Package (BSP) – normal
language
Or, Linux Support Package (LSP) – Linux
language

Sources of LSPs
Board Vendor
For a reference board, Or
For a board based on the reference design
Develop your Own for a Custom Board
developed In-House
First, search the kernel source for existing code
If found, use it
Else, if found something close, modify & use it
Otherwise, following material would provide
further guidelines

Architecture of Linux Support Packages

Components of LSP
As LSP is very specific to a board. It consists
of code for things hard-wired on the board
A Usual List
Interrupt Request Numbers
Audio Codecs
Keypad Interfaces
Switch Interfaces
LED Interfaces
...

LSP Placement
With these in mind, and a board being tied to an architecture, the
natural place for an LSP becomes under the kernel's “arch” sub-tree
To be more specific, under the specific <arch> of the arch/
Architecture Specific Code resides under
arch/<arch> → Sources
include/asm-<arch> → Headers
So, Board Specific Code resides under
arch/<arch>/mach-<board_name> → Sources
include/asm/mach-<board_name> → Headers
mach stands for Machine, lingo for Board in Linux community
Many LSP vendors, violate these norms, and
Place headers with sources
Place the LSP at other inappropriate locations

Design & Layout of LSPs
Where does a keypad driver go?
Under drivers, Or
Linux Support Package
What about code for Audio chip, when the controller doesn't have
built-in audio support (say I2S)?
Such gray areas create confusion
People place the code as per their judgment
Hence, we follow some thumb rules
Design & Layout Rules of Thumb
Look for something similar, already in kernel source
Follow the norm
If not there, start from the LSP
Over time, if it becomes generic enough, move to drivers
For all the above, appropriately update Kconfig & Makefile

Initialization Code LSP
Board specific Code
UART Configuration – UART Pins, UART vs
Device mapping, ...
Ethernet Configuration – Interrupt Pin, ...
… (the various device configurations)
Let's browse the code
mach-omap2/board-omap3evm.c
plat-omap/...

Custom Code LSP
Interrupts
Input / Output Management
Audio
Video
Embedded Storage Management
Flash Partitioning
NB Separate sessions needed for each

Let's Browse some LSPs

BSP in Bootloader
Bootloader does some of the Board-specific
tasks, which are done in kernel
Device Initialization
Some Device Access
This could be taken advantage from
Could serve as the reference for the LSP
Many a times, it becomes other way round
Code developed for LSP may help enhance
Bootloader
Improving a better Board Bringup Experience

Board Id
Unique Number designated to every
Board Type
Part of the LSP and exposed to Bootloader
Populated by Bootloader
Verified by LSP
Let's browse to view it
arch/arm/tools/mach-types

Hacking the LSP
Very often, we have initial boot, test &
board bringup programs, written to run
on the bare board
They may be really useful to hack the LSP
When it is not working as expected

Steps in Porting
Register the machine and get the machine id for board
Create a board specific file 'board-<board_name>' at
arch/arm/mach-<soc>
Define the MACHINE_START for the board
Update the Kconfig file at arch/arm/mach-<soc>
Update the corresponding makefile
Create the default configuration for the board and place the
working .config file at arch/arm/configs/

What all have we learnt?
Kernel Basics for Linux Porting
W's of Linux Porting
W's of Linux Support Package (LSP)
Architecture of LSPs
Browse & Understand the LSPs

Any Queries?

Linux Porting

More Related Content

What's hot

Viewers also liked

Similar to Linux Porting

More from Anil Kumar Pugalia

Recently uploaded

Linux Porting