Embedded Operating System - Linux

Team Emertxe
Embedded Operating System
Linux

Embedded Operating System - Linux
Contents
●
Embedded Systems Introduction
●
Linux as Embedded Operating System
●
Embedded Development and its Environment
● Overview of the Target – Peripherals and Interfacing
●
Booting Sequences
● Embedded Linux Kernel
●
File Systems

Embedded Linux
●
Open Source & Free Software Fundamentals
● Why to choose Linux
●
Architecture
● Choices to Make

Open Source
How it all started?
● With GNU (GNU is not UNIX)
● Richard Stallman made the initial announcement in 1983, Free
Software Foundation (FSF) got formed during 1984
● Volunteer driven GNU started developing multiple projects,
but making it as an operating system was always a challenge
●
During 1991 a Finnish Engineer Linus Torvalds developed core
OS functionality, called it as “Linux Kernel”
● Linux Kernel got licensed under GPL, which laid strong
platform for the success of Open Source
● Rest is history!

● Multiple Linux distributions started emerging around the
Kernel
● Some applications became platform independent
●
Community driven software development started picking up
●
Initially seen as a “geek-phenomenon”, eventually turned out
to be an engineering marvel
● Centered around Internet
● Building a business around open source started becoming
viable
● Redhat set the initial trend in the OS business
Open Source
How it evolved?

OS Databases Server/Cloud Enterprise
Consumer Education CMS eCommerce
Open Source
Where it stands now?

●
4 Freedoms
– Copy,
– Study,
– Change,
– Use
● The above freedom are for both commercial and
non-commercial use
● Free Software Licenses – GNU GPL and GNU FDL
Free Software
What does it mean?

●
Quality and Reliability of Code
● Availability of Code
●
Hardware Support
● Communication Protocols and Software Stds
●
Available Tools
● Community Support
●
Licensing
●
Vendor Independence
●
Cost
Embedded Linux
Why Choose!

●
Modularity and Structure
● Readability of Code
●
Extensibility
● Configurable
●
Predictability
● Error Recovery
●
Longevity
Embedded Linux
Why Choose! – Quality and Reliability of Code

● ARM
– Suits well for Embedded
– Include THUMB – reduce code bandwidth
– High density code than PPC, x86.
●
Power PC
– Intended for PC
– Have become popular in embedded
● Strong ARM
– Faster CPU – Higher Performance
– PDAs, Setup box etc.,
● MIPS
And many more !!
Embedded Linux
Ported Architectures

●
Which kernel to use?
● Which development environment:
●
Which compiler, debugger, dev boards?
● Which drivers and libraries?
●
Support and training?
Embedded Linux
Choices to Make

Target Development &
Environment

Embedded Development & Environment
●
Typical System Components
● Hardware Tools and Interfacing
●
Software Environments Tools
● Toolchains

Typical System Components
Hardware
Boot Loaders
Operating System
Libraries
Applications
Tools

Hardware Tools and Interfacing
Possible Connections
Serial
Network
USB
JTAG
Emulators
OTA

Software Environment Tools
Serial
Network
minicom
gtkterm
TFTP
NFS

Toolchain
Introduction
● Set of applications used to perform a complex task or to
create a product, which is typically another computer program
or a system of programs.
● Tools are linked (or chained) together by specific stages
● Output or resulting environment state of each tool becomes
the input or starting environment for the next one
● By default the host contains some development tools which
ate called as native toolchain

Toolchain
Introduction
●
When you use these tool the code generation would be
for native architecture (say x86)
● In case of developing embedded systems these toolchains
does not serve the purpose
● The targets some times might have the following
restrictions too!
– Less memory footprints
– Slow compared to host
– You may not wish to have in a developed system finally
● So cross compiling toolchain are used

Toolchain
Introduction - Flow
Native
Tools
Cross Compiling
Tools

Toolchain
Components
Compiler
Binary Utilities
C / C++ Libraries
Kernel Headers
Debuggers

Toolchain
Components – GCC
●
Abbreviated as GNU Compiler Collection, one of the
famous free software compiler
● Can compile many programming languages and generate
code for many different types of architecture

Toolchain
Components – Binary Utilities
●
Set of programming tools for creating and managing
binary programs, object files, libraries, profile data, and
assembly source code
●
Includes an assembler, linker and several other software
tools
●
Often used with a compiler and libraries to design
programs for Linux
● GNU Binary Utilities are called binutils

Toolchain
Components – binutils
●
as - the assembler, that generates binary code from
assembler source code
● ld - the linker
●
ar, ranlib - to generate .a archives, used for libraries
●
objdump, readelf, size, nm, strings - to inspect binaries.
Very useful analysis tools !
● strip - to strip useless parts of binaries in order to reduce
their size

Toolchain
Components - Libraries
●
The C library is an essential
component which provides
interface between the
applications and the kernel
●
Provides macros, type
definitions, and functions for
tasks like string handling,
mathematical computations,
input/output processing,
memory allocation and
several other operating
system services

Toolchain
Components - Libraries
●
Several C libraries are available: glibc, uClibc, dietlibc,
etc
● The selection of the library has to be made while
generation the toolchain as gcc is compiled against the
selected library
●
Some common used libraries
– glibc
– uclibc

Toolchain
Components – Libraries - glibc
●
C library from the GNU project
●
Good performance optimization, standards compliance
and portability
●
Well maintained and used on all GNU / Linux host systems
●
Require large memory footprint making it not suitable for
small embedded systems
● Used in systems that run many different kernels and
different hardware architectures
●
License: LGPL
●
Website: http://www.gnu.org/software/libc/

Toolchain
Components – Libraries - uclibc
●
Smaller than the GNU C Library, but nearly all applications
supported by glibc also work perfectly with uClibc
●
Recommended for lower footprint embedded systems
●
Excellent configuration options at the cost of ABI
differences for different configurations
●
Features can be enabled or disabled according to space
requirements
●
Works on most embedded architectures with embedded
Linux
●
Focus on size rather than performance with less compile
time

Toolchain

Toolchain
●
Created for support uclinux, a Linux for MMU less system
●
Actively maintained, large developer and user base
●
Used on a large number of production embedded
products, including consumer electronic devices

Toolchain
Components – Kernel Headers
●
The compiled applications and
the libraries sometimes need to
interact with the kernel
●
So the Linux kernel need to
expose the available interfaces
for the libraries and applications
to use, like
– System calls and its numbers
– MACRO definitions
– Data structures, etc.

Toolchain
Components – Kernel Headers
●
Therefore, compiling the C library requires kernel
headers, and many applications also require them.
● You may find these in <linux/...> and <asm/...> and a
few other directories corresponding to the ones visible in
include/ in the kernel sources
●
Compatibility with running kernel has to be considered

Toolchain
Building
●
Toolchain building is one of the time consuming process
●
A very clear picture of the system architecture is
sometimes required
●
We might have to identify three systems in this case, like
– Build System – which is used to create the toolchain
– Host – which will be used to execute the created toolchain
– Target – which will execute the binaries created by the
toolchain
●
So by considering the above points some possible build
options are provided in next slide

Toolchain
Building
●
Possible Build System
●
Build Considerations
●
Toolchain Build Possibilities
– Prebuilt
– Home Built
– Automated Tools
●
Crosstool NG
●
Buildroot
● Yocto

Toolchain
Building – Build Systems
Native Build Cross Build
Canadian BuildCross Native Build

Toolchain
Building - Considerations
●
Before building the toolchain following decisions have to
be made
– Which library to be used?
– What version of the components to selected?
– Certain important configurations like
●
Architecture features like floating point
● ABI selections
● Networking features etc.,
●
So you might have to put good amount of time in
investigations

Toolchain
Building – Pre-built
● Get a pre-built open toolchain either from a web or from your
hardware vendor
● This is the easiest solution, as the toolchain is already built,
and has supposedly been tested by the vendor
● The drawback is that, you don't have flexibility on your
toolchain features (which C library? hard-float or soft-float?
which ABI?)

Toolchain
Building – Home Built
●
Building toolchain from scratch is one of the tiring and
time consuming task which might go upto several weeks.
● Several information to be known. Lots of components to
be considered to build.
● Proper decision on the components and its configuration
have to be made
●
Need kernel headers and C library sources
●
There are version dependency issues, patches required to
make something work etc.
● The order of build is to be known, but have complete
freedom of choice

Toolchain
Building – Home Built
● Can get some idea from the crosstool matrix by Kegel (Note
this is outdated)

Toolchain
Building – Automated Tools
●
Lots of open community has built several scripts or more
elaborate systems to ease the process of building a
toolchain
●
More easy procedure since no need of breaking your
heads on dependency resolutions
●
Provides easy configuration mechanism
●
Recipes and patches needed to build a toolchain made of
particular versions of the various components are shared
and easily available
● Some common automated tools are discussed in following
slides

Toolchain
Building – Automated Tools – Crosstool-NG
●
Updated version of Crosstool, with a kernel-like
menuconfig like configuration system
● Supports uClibc, glibc, eglibc, hard and soft float, many
architectures
● Support different target OS: Linux, bare metal
●
Debug facilities like native and cross gdb, gdb server
● Actively maintained
●
Targeted at building toolchains
● http://crosstool-ng.org/

Toolchain
Building – Automated Tools – Buildroot
●
Buildroot is a set of Makefiles and patches that makes it
easy to generate a complete embedded Linux system
● Generates root file system images ready to be used
●
Complete build system based on the Linux Kernel
configuration system and supports a wide range of target
architectures
●
It automates the building process of your embedded
system and eases the cross-compilation process
●
Supports multiple filesystem types for the root
filesystem image

Toolchain
Building – Automated Tools – Buildroot
●
Can generate an (e)glibc or uClibc cross-compilation
toolchain, or re-use your existing glibc, eglibc or uClibc
cross-compilation toolchain
●
Supports several hundreds of packages for userspace
applications and libraries
●
http://buildroot.uclibc.org

Toolchain
Building – Automated Tools – Yocto
●
The Yocto Project is a Linux Foundation work group
initiated to create Linux distribution for embedded systems
●
Provides inter-operable tools, meta-data, and processes
that enable the rapid, repeatable development of Linux-
based embedded systems.
●
Builds using Python and Shell scripts, and a task scheduler
called BitBake
●
Complex method than Buildroot
●
Actively maintained
●
Targeted at building Linux Distributions
●
https://www.yoctoproject.org/

Buildroot
Introduction
●
Buildroot is a set of Makefiles and patches that makes it
easy to generate a complete embedded Linux system
● Generates root file system images ready to be used
●
Complete build system based on the Linux Kernel
configuration system and supports a wide range of target
architectures
●
It automates the building process of your embedded
system and eases the cross-compilation process
●
Supports multiple filesystem types for the root
filesystem image

Buildroot
Introduction
●
Can generate an (e)glibc or uClibc cross-compilation
toolchain, or re-use your existing glibc, eglibc or uClibc
cross-compilation toolchain
●
Supports several hundreds of packages for userspace
applications and libraries
●
http://buildroot.uclibc.org

Buildroot
Configuration
● Download buildroot package from http://buildroot.uclibc.org
● Untar the package and change directory to buildroot
$ tar xvf buildroot-<year>-<month>.tar.bz2
$ cd buildroot-<year>-<month>
● Buildroot supports Linux kernel like configuration options like
menuconfig, xconfig etc.,
● To configure type
$ make menuconfig
● You should get a curses based configurator

Buildroot
Configuration
● Select the target architecture you want to work with
● You may select the toolchain components like
– kernel headers
– binutils
– uclibc
– gcc etc.,
● You can ignore selecting these components buy selecting the
target architecture, but the default selected components
would be used while building

Buildroot
Building
● To start the build process just type
$ make
● Make sure you don't use make -jN option. Instead you can use
BR2_JLEVEL option to run compilation of each individual
package with make -jN
● BR2_JLEVEL can be set while configuration at
Build options Number of jobs to run simultaneously→

Buildroot
Building
● The make command will generally perform:
– Download source files (as required)
– Configure, build and install the cross compilation toolchain,
or simply import an external toolchain
– Configure, build and install selected target packages
– Build kernel, bootloader images if selected
– Create the root filesystem in selected format
● Buildroot output is stored in a single directory named output/
which will be found in the root directory of buildroot

Buildroot
Building - Output
●
The left side shows contents the output
directory of the buildroot folder
●
This directory contains several subdirectories
●
The following slides discuss its contents
images
build
staging
buildroot-<YYYY>.<MM>
target
host
output

Buildroot
Building - Output
●
All the built images like kernel, bootloader,
filesystem are stored here
●
These are the files you need to put on the
target system
images
build
staging
target
host
output

Buildroot
Building - Output
●
All the components are built here (this
includes tools needed by Buildroot on the host
and packages compiled for the target)
●
Contains one sub directory for each of these
components
images
build
staging
target
host
output

Buildroot
Building - Output
●
Contains a hierarchy similar to a root
filesystem hierarchy
●
Contains the headers and libraries of the
cross-compilation toolchain and all the
userspace packages selected for the target
● This directory is not intended to be the root
filesystem for the target: it contains a lot of
development files, unstripped binaries and
libraries that make it far too big for an
embedded system
●
These development files are used to compile
libraries and applications for the target that
depend on other libraries
images
build
staging
target
host
output

Buildroot
Building - Output
● Contains almost the complete root filesystem
for the target: everything needed is present
except the device files in /dev/ and It doesn’t
have the correct permissions
●
Therefore, this directory should not be used on
your target
● Instead, you should use one of the images built
in the images/ directory
●
If you need an extracted image of the root
filesystem for booting over NFS, then use the
tarball image generated in images/ and extract
it as root
● Contains only the files and libraries needed to
run the selected target applications: the
development files (headers, etc.) are not
present, the binaries are stripped
images
build
staging
target
host
output

Buildroot
Building - Output
●
Contains the installation of tools compiled for
the host that are needed for the proper
execution of Buildroot, including the cross-
compilation toolchain
images
build
staging
target
host
output

Buildroot
More Infos!!
● http://buildroot.uclibc.org/downloads/manual/manual.html

EmxDev Boards – EmxARM9A03
Target Overview
●
Know your Target Controller
● Target Architecture
●
Target Board

Target Overview - Target Controller
● ARM920T
– 200MIPS at 180MHz, MMU
– 16KB Inst & Data Cache
– ICE
●
Memories
– 128 ROM, 16 KB SRAM
– EBI
– SDRAM, SM,CF, NOR, NAND
●
Ethernet MAX 10/100
●
USB 2.0 FS Host
● USB 2.0 FS Device
● MCI
●
SSC
●
USART
– Smart Card
– RS485, RS232
– IrDA
– Modem
● I2C, SPI
●
Debug Unit

Target Overview - Target Architecture

Target Overview - Base Board

Target Overview - Application Board

Booting Sequence
Linux as general
System Start-up BIOS / Boot Monitor
Stage 1 Boot Loader Master Boot Record
Stage 2 Boot Loader LILO, GRUB, etc
Kernel Linux
Init User Application

Booting Sequence
●
Controller's Booting Sequence
●
Boot Loader Stages

Booting Sequence - Controller's Boot Sequence
Device
Setup
SPI
Data Flash
Parallel
Boot
OR
Download from
Data Flash
Download from
EEPROM
Download from
8 bit Device
DBGU Serial
Download
USB Download
DFU Protocol
RUN
RUN
RUN
RUN
RUN
TWI
EEPROM Boot

●
Stage 1 Boot Loader
●
Stage 2 Boot Loader
Booting Sequence – Boot Loader Stages

● Pointer to Stage 2 Boot Loader
Booting Sequence – Stage 1 Boot Loader
ROM
(ROM Code)
SRAM
Memory
(serial / parallel)
(S1BL)
Stage 2
Boot Loader
Kernel
Data
Memory
(parallel)

● Pointer to Kernel Image
●
We use U-Boot as S2BL
Booting Sequence – Stage 2 Boot Loader
Memory
(parallel)
Stage 2
Boot Loader
Kernel
Data

U-Boot
Introduction - General
●
The "Universal Bootloader" ("Das U-Boot") is a monitor
program
● Free Software: full source code under GPL
● Can get at: //www.denx.de/wiki/U-Boot
●
Production quality: used as default boot loader by several
board vendors
●
Portable and easy to port and to debug
● Many supported architectures: PPC, ARM, MIPS, x86,
m68k, NIOS, Microblaze

U-Boot
Introduction - General
●
More than 216 boards supported by public source tree
●
Simple user interface: CLI or Hush shell
●
Environment variable storing option on different media
like EEPROM, Flash etc
●
Advanced command supports

U-Boot
Introduction – Design Principles
●
Easy to port to new architectures, new processors, and
new boards
● Easy to debug: serial console output as soon as possible
●
Features and commands configurable
●
As small as possible
●
As reliable as possible

U-Boot
Source Code Browsing
●
Untar the U-Boot code
– tar xvf u-boot-<version>.tar.bz2
●
Enter the U-Boot directory
– cd u-boot-<version>
● The following slide discuss the contents of the U-Boot
directory

U-Boot
Source Tree
● The left side of the slide
shows the source content of
the U-Boot
● The directory structure might
vary depending on the picked
version.
● The considered version is
u-boot-2015-01
● Lets us discuss some
important directories and files
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Machine/arch independent API
for external apps
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● All architecture dependent
functions
● CPU specific information
– <core>/cpu.c
– <core>/interrupt.c
– <core>/start.S
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Platform, board level files.
Eg, atmel, icecube, oxc etc.,
● Contains all board specific
initialization
– <boardname>/flash.c
– <boardname>/<boardname>_emac.c
– <boardname>/<boardname>.c
– <boardname>/soc.h
– <boardname>/platform.S
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● All architecture independent
functions
● All the commands
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Default configuration files for
boards
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Partition and device
information for disks
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● You can find all the README
files here
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Various device drivers files
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Contains Makefile for building
internal U-Boot fdt
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Example code for standalone
application
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● File system directories and
codes
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Various header files
– configs/<boardname>.h
– <core>.h
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Processor specific libraries
– board.c
– <arch>linux.c
– div0.c
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Networking related files.
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Power On Self Test
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Contains the sources for
various helper programs
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Various tools directories and
files
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Source Tree
● Top level make file for Uboot
build and configuration
driver
api
arch
board
common
configs
post
scripts
dts
examples
fs
include
lib
test
tools
Makefile
disk net
doc
u-boot-<version>

U-Boot
Building
●
The include/configs/ directory contains one configuration
file for each supported board
– It defines the CPU type, the peripherals and their
configuration, the memory mapping, the Uboot features
that should be compiled in, etc.
– It is a simple .h file that sets preprocessor constants. See
the README file for the documentation of these constants.
●
Assuming that your board is already supported by Uboot,
there should be a config corresponding to your board, for
example include/configs/at91rm9200ek.h

U-Boot
Building
●
We need to configure U-Boot for the required board
which is generally done as
make <board_name>_config
● The board_name can be found in include/configs/
directory
● The newer version supports kernel like configuration
options like make menuconfig
●
Compile Uboot, by specifying the cross compiler prefix.
make CROSS_COMPILE=<cross_compile_path>

U-Boot
Building
● cross_compile_path could be the command itself if
already exported in PATH variable, else you can specify
the installation path of command
● For example for arm platform it would look like
make CROSS_COMPILE=arm-linux-
● The result would be u-boot.bin which has to be stored in
flash memory (in most of the cases)
● The invocation of the stored image depends on the target
architecture. The memory used to store would play the
role here

U-Boot
Responsibility
Execute from flash (If configured). Do POST
Relocate to RAM
Setup console for user interaction
Setup device driver for kernel (& RFS) image
Choose the kernel (& RFS) image
Download the kernel (& RFS) image
Choose the kernel (& RFS) imageChoose the kernel (& RFS) image
Setup kernel command line arguments
Jump to kernel start address
Codeflow

U-Boot
Utilities
●
Environment Variables
●
Commands
– Information
– Environment
– Network
– Boot
– Data Transfer
– Memory

U-Boot
Environment Variables
● bootcmd : Contains the command that U-Boot will
automatically execute at boot time after
a configurable delay, if the process is not
interrupted
● bootargs : contains the arguments passed to the
Linux kernel
● serverip : Server (Host) ip address for network
related commands
● ipaddr : Local ip address of the target
● ethaddr : MAC address. Will be set once

U-Boot
Important Environment Variables
● netmask : The network mask to communicate with
the server
● bootdelay : Time in seconds to delay the boot process
so that the u-boot can be interrupted
before executing bootcmd
● autostart : If set the loaded image in memory will be
executed automatically

U-Boot
Important Commands – Information
● help : Help command. Can be used to list all
supported built commands
● flinfo : Display flash informations (NOR and SPI
Flash)
● nand info : Display NAND flash informations

U-Boot
Important Commands – Environment
● printenv : Print all set environment variables
● setenv : Set the environment variable
● saveenv : Save environment variable to configured
memory

U-Boot
Important Commands – Network
● ping : Checks for network connectivity

U-Boot
Important Commands – Boot
● boot : Runs the default boot command, stored in
bootcmd variable
● bootm : Boot memory. Starts a kernel image
loaded at the specified address in RAM
Example: bootm <address>

U-Boot
Important Commands – Data Transfer
● loadb
● loads
● loady
: Load a file from the serial line to RAM
● tftpboot : Loads a file from the network to RAM
Example: tftpboot <address>

U-Boot
Important Commands – Memory
● erase : Erase the content of NOR flash
● protect : Protect the content of NOR flash
● cp : Write to NOR flash
● nand : Erase, read, write to NAND flash

Embedded Linux Kernel
General Information

General Information
●
Where to get?
● Kernel Subsystem
●
Source Code Browsing

General Information – Where to get?
Note: Snapshot of www.kernel.org. Expect changes on updates

General Information – Kernel Subsystem
● Process Scheduler:
– To provide control, fair
access of CPU to process,
while interacting with HW on
time
●
Memory Manager:
– To access system memory
securely and efficiently by
multiple processes. Supports
Virtual Memory in case of
huge memory requirement
● Virtual File System:
– Abstracts the details of the
variety of hardware devices
by presenting a common file
interface to all devices

General Information – Kernel Subsystem
● Network Interface:
– provides access to several
networking standards and a
variety of network hardware
● Inter Process
Communications:
– supports several
mechanisms for process-to-
process communication on a
single Linux system

General Information – Source Code Browsing
●
Untar the Linux kernel code
– tar xvf linux-<version>.<compression_format>
●
Enter the Linux kernel directory
– cd linux-<version>
● The following slide discuss the contents of the Linux
directory

● The left side of the slide shows
the source content of the Linux
kernel
● The directory structure might
vary depending on the picked
version.
● Lets us discuss some important
directories and files
init
arch
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>

● Architecture specific kernel
code
● Has sub directories per
supported architecture
●
Example:
– arm
– powerpc
– X86
●
We can also find low level
memory management, interrupt
handling, early inits, assembly
code and much more
init
arch
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>

● Contains core block layer files
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Cryptographic API for use by
kernel itself
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains system's device drivers
● Sub directories contain classes
of device drivers like video
drivers, network card drives,
low level SCSI drivers etc.,
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains the device firmwares
which will be uploaded to
devices with help of drivers
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● File system related code
● Contains both generic file
system code (VFS) and different
files system code
●
Sub directories of supported file
system
● Examples:
– ext2
– ext3
– fat
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Most of the header files used in
the .c file of the kernel source
● It has further sub directories
including asm-generic
●
Architecture specific header
file would be found in
arch/<arch>/include/
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch
Note: File level organization will vary based
on different versions of kernel sources
especially architecture and machine related
header files

● Initialization code for kernel
● Best directory to start with to
know on how kernel works
●
Has main.c of kernel
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains kernel's inter process
communication code like shared
memory, semaphores and other
forms
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Generic kernel level code which
can't fit anywhere else
● Contain upper level codes for
signal handling, scheduling
etc.,
● The architecture specific kernel
code will be in
arch/<arch_name>/kernel
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains kernel's library code
● Common string operations,
code for debugging and
command line parsing code can
be found here
● The architecture specific library
code will be in
arch/<arch_name>/lib
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains memory management
code
● The architecture specific
memory management code
would be found in
arch/<arch_name>/mm
● Example:
– arch/x86/mm/init.c
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● The kernels networking code
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Some sample programs
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains scripts that are used
while kernel configuration
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains code for different
security models
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains all the sound card
drivers
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Certain configuration and
testing tools
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● Contains code that builds a
cpio-format archive containing
a root file system image, which
will be used for early userspace
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

● This is top level Makefile for
the whole source tree
● Contains useful rules and
variables like default gcc
compilation flags
init
block
crypto
drivers
firmware
scripts
security
ipc
kernel
lib
mm
net
sound
tools
usr
Makefile
fs samples
include
linux-<version>
arch

Configuration

Configuration
●
The kernel configuration is based on multiple Makefiles
● As discussed already the top level Makefile would be
used for this purpose
●
The configuration you should know the target. You can
find of the target as mentioned below
$ cd linux-<version>
$ make help
● Now you may look for “Configuration targets:” section of
the output and decide one

Configuration
●
Once you decide on the target you may try the following
command
$ make target
● The modified configurations would be saved on a file
called as .config which can be found on the top level of
the linux-<version> directory.
● All the target options use the same .config file, so you
may use any interchangeably.

Configuration
●
Some most commonly used target are
– make config
– make menuconfig
– make xconfig
●
Configuring Architecture specific targets
●
Configuring for specific architecture from scratch

Configuration – make config
user@hostname:linux-<version>$ make config
scripts/kconfig/conf --oldaskconfig Kconfig
*
* Linux/<ARCH> <version> Kernel Configuration
*
Patch physical to virtual translations at runtime (ARCH_PATCH_PHYS_VIRT) [Y/n/?]
●
The above image show snap shot typical output of make config
command
●
Updates current config utilizing a line-oriented program
●
No user friendly approach. Could be used if you have limited host
installations
●
The problem with this approach is that, It force you to follow an
sequence of questions while configuration.
●
Have to use “Ctrl C” to exit

Configuration – make menuconfig
●
The above image shows the snapshot of typical output of make
menuconfig command

Configuration – make menuconfig
●
Most commonly used method and simple method
● Can be used if graphics is unavailable
●
Requires libncurses-dev installation
● Easy to navigate between options, using arrow keys
●
Use <Help> to know more on menuconfig

Configuration – make xconfig
●
The above image shows the snapshot of typical output of make xconfig
command

Configuration – make xconfig
●
Most commonly used graphical method of configuration
● Easy to use, better search option
●
Use Help menu to know more on xconfig
● Requires libqt-dev packages installation

Configuration – Architecture Specific
●
Most preferably used in Embedded Linux configuration
● You can find then at arch/<arch>/configs/
● These files are best possible minimal .config file you can have
for your board
● Just type the following on the command to know available
target
$ make help
– Now you may look for “Architecture specific targets:” section of the
output to look for default configuration for your target architecture
● Now the following command
$ make <controller_name>_defconfig

Configuration – Architecture Specific
●
The previous command would rewrite the existing .config file.
● Now you can use any of the general configuration method to
discussed above to configure further if required
● If you feel the you are done and need to preserve your
configuration then you can save it by
$ make savedefconfig
● The above line will create a file call defconfig on root of
kernel source directory
● Now you can mv it to the config directory by the following
command
$ mv defconfig /arch/<arch>/configs/my_defconfig

Configuration – From Scratch
● Its possible to configure a kernel from scratch without using
any default configuration
●
It would obvious if your a board vendor where you might
have to do for your board
● Point to be kept in mind in this case
– Make sure you alteast select a proper architecture for your board
– Most of the architecture dependent basic things would be set by
default, so just leave it as it is, unless you know what you
change
– Might have to change certain thing like select a correct device
driver for your board

Building

● Assuming the required configuration are done, The next
step would be to compile the kernel.
●
Type the following command on the prompt to start the
compilation
make
● Can use the below command if you have multicore CPU
make -j
● The above command will speed up your compilation process
● You may even specify the no of jobs you want to run
simultaneously based on your CPU configuration
Building - Compilation

● Once the compilation is done you will get the kernel image
in the following location arch/<arch>/boot
● make install this is rarely used in embedded dev as the
kernel image is single file, But still can be done by
modifying its behavior arch/<arch>/boot/install.sh
●
You can install all the configured modules by the following
command
make INSTALL_MOD_PATH=<dir>/ module_install
● The above line direct the module installation on the path
provided by the INSTALL_MOD_PATH variable and this is
important to avoid installation in host root path

●
Most of the embedded system uses U-Boot as its second
stage boot loader
●
U-Boot require the kernel image to be converted into a
format which it can load. This converted format is called
as uImage
●
The discussion done here is on how create the uImage
from vmlinux
●
vmlinux is the output of the kernel compilation which you
would find on the root directory of the kernel directory
● vmlinux consists of multiple information like ELF header,
COFF and binary
Building – Kernel Image

●
So it required to extract the binary file from the vmlinux
first, Which is done by the following command
arm-linux-objcopy -O binary vimlinux linux.bin
● After extraction the U-Boot header can be added using
mkimage command, This is done by the following
command
mkimage -A arm -O linux -T kernel -C none -a
20008000 -e 20008000 -n “Embedded Linux” -d
linux.bin uImage.arm
●
After all the above steps the kernel image is ready for
deployment on target
Building - Kernel Image

Deploy
●
Assuming the host is already configured with TFTP server
and Target is running U-Boot with TFTP client
●
Copy uImage.arm in /var/lib/tftpboot/
●
Copy the kernel image to the target board as mentioned
below
U-boot> tftp <TEXTBASE_ADDRESS> uImage.arm
● TEXTBASE_ADDRESS is defined configuring u-boot
●
Once the image is transferred you can boot the image as
U-boot> bootm
●
Your kernel should be loaded and executed now :)

File Systems
●
Introduction
● Building FS from scratch

File Systems
Introduction
●
File system is an approach on how the data can be
organized in order to have a meaningful read or write in a
system
●
File systems provides a very easy way of identifying data
like where it begins and ends
●
The group of such data can be called as “Files”
●
The method used to manage these groups of data can be
called as “File systems”

File Systems
Introduction
●
There are several kinds file system having different structure
and logic, properties of speed, flexibility, security, size and
more
●
The most commonly used media to store the data are
– Storage Devices
●
Magnetic Tapes
●
Hard Drive
●
Optical Discs
●
Flash Memories
●
RAM (Temporary)
– Network like NFS
– Virtual like procfs

File Systems
Introduction
●
An OS can support more than one file system
●
In this topic we are going to concentrate on Unix and
Unix like file systems
●
File systems can be discussed in the following context
– Contents
– Types
– Partitions

File System Contents
Linux Directory Structure

●
When it is the matter of data, different operating system
uses different approaches to organize it
● In Unix and Unix like systems, applications and users see
a single global hierarchy of files and directories, which
can be composed of several file systems.
●
The access of the data are done using a process called as
mounting
● The location on where the data should be located called
as mount point is to be informed to the OS.
● The following slides discuss about the Linux Directory
Structure

●
The left side of the slide shows the
most important files in Linux system
● The organization of a Linux root file
system in terms of directories is well
defined by the Filesystem Hierarchy
Standard
●
Most Linux systems conform to this
specification
– Applications expect this organization
– It makes it easier for developers and
users as the file system organization is
similar in all systems
tmp
sys
usr
var
/
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

● Place for most commonly used
terminal commands
● Common Linux commands you
need to use in single-user modes
are located under this directory.
● Commands used by all the users of
the system are located here.
● Examples:
– ls
– ping
– grep
– cp
bin
tmp
sys
usr
var
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

● Contains files needed to start up
the system, including the Linux
kernel, a RAM disk image and
bootloader configuration files
● Kernel image (only when the
kernel is loaded from a file
system, not common on non-x86
architectures)
boot
tmp
sys
usr
var
bin
dev
home
media
proc
sbin
etc
lib
mnt
root

● Device files
● These include terminal
devices, usb, or any device
attached to the system.
● Examples:
– /dev/tty1
– /dev/usbmon0
dev
tmp
sys
usr
var
bin
home
media
proc
sbin
boot
etc
lib
mnt
root

● Contains configuration files
required by all programs.
● This also contains startup and
shutdown shell scripts used to
start/stop individual programs.
● Examples:
– /etc/resolv.conf
– /etc/logrotate.conf
etc
tmp
sys
usr
var
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

● Home directories for all users to
store their personal files.
● Example:
– /home/arun
– /home/adilhome
tmp
sys
usr
var
bin
dev
media
proc
sbin
boot
etc
lib
mnt
root

● Contains library files that supports
the binaries located under /bin
and /sbin
● Library file names are either ld* or
lib*.so.*
● Examples:
– ld-2.11.1.so
– libncurses.so.5.7
lib
tmp
sys
usr
var
bin
dev
home
media
proc
sbin
boot
etc
mnt
root

● Temporary mount directory for
removable devices.
● Examples:
– /media/cdrom
– /media/floppy
– /media/cdrecorder
media
tmp
sys
usr
var
bin
dev
home
proc
sbin
boot
etc
lib
mnt
root

● Temporary mount directory where
sysadmins can mount file systems.
mnt
tmp
sys
usr
var
bin
dev
home
media
proc
sbin
boot
etc
lib
root

● Contains information about system
process.
● This is a pseudo file system
contains information about running
process. For example: /proc/{pid}
directory contains information
about the process with that
particular pid.
● This is a virtual file system with
text information about system
resources. Examples:
– /proc/uptime
proc
tmp
sys
usr
var
bin
dev
home
media
sbin
boot
etc
lib
mnt
root

● Root user's home directory
root
tmp
sys
usr
var
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt

● Just like /bin, /sbin also contains
binary executables
● But, the Linux commands located
under this directory are used
typically by system administrator,
for system maintenance purpose.
● Examples:
– iptables
– reboot
– fdisk
– ifconfig
– swapon
sbin
tmp
sys
usr
var
bin
dev
home
media
proc
boot
etc
lib
mnt
root

● Mount point of the sysfs virtual file
system
sys
tmp
usr
var
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

● Directory that contains temporary
files created by system and users.
● Files under this directory are
deleted when system is rebooted.
tmp
sys
usr
var
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

● Contains binaries, libraries, documentation,
and source-code for second level programs.
●
/usr/bin contains binary files for user
programs. If you can’t find a user binary
under /bin, look under /usr/bin. For
Examples: at, awk, cc, less, scp
●
/usr/sbin contains binary files for system
administrators. If you can’t find a system
binary under /sbin, look under /usr/sbin.
For Examples: atd, cron, sshd, useradd,
userdel
●
/usr/lib contains libraries for /usr/bin
and /usr/sbin
●
/usr/local contains users programs that you
install from source. For example, when you
install apache from source, it goes under
/usr/local/apache2
usr
tmp
sys
var
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

● var stands for variable files.
● Content of the files that are
expected to grow can be found
under this directory.
●
This includes —
– /var/log - system log files
– /var/lib - packages and database files
– /var/mail - emails
– /var/spool - print queues
– /var/lock - lock files
– /var/tmp - temp files needed across
reboots
var
tmp
sys
usr
bin
dev
home
media
proc
sbin
boot
etc
lib
mnt
root

File System Types
Introduction
●
Variety of choices available based on
– Speed
– Size
– Reliability
– Access restrictions
●
Some types are specifically targeted based on the storage
media
●
The following slide discuss some of the most commonly
used types

File System Types
Introduction
●
RAM File Systems
– initrd
– initramfs
●
Disk File Systems
– ext2
– ext3
– ext4
– Flash File Systems
●
Intro to MTD
● JFFS2

File System Formats
Variants
●
Distributed File Systems
– NFS
●
Special Purpose File Systems
– squashfs

File System Types
RAM File Systems

File System Types
RAM File Systems - initrd
●
Abbreviated as initial RAM disk
●
RAM based block device with fixed size formatted and
mounted like disk at /dev/ram
●
The size problem
– Sometimes might be a waste of space if its not fully
utilized
– You can extend the limit later on run time as it has to be
reformatted
●
Requires a file system driver compiled statically into
kernel to interpret data at run time
●
ext2 format mostly used for creation

File System Types
RAM File Systems - initrd
●
Typical boot process using initrd is as followed
– Bootloader loads the kernel and initrd into ram
– Kernel converts the initrd into a normal RAM disk and frees the
memory used by initrd
– initrd is mounted as read write as root
– /linuxrc is executed (could be a executable, shell script)
– linuxrc mounts the real root file system
– linuxrc places the root file system at the root directory using the
pivot_root system call
– The normal boot is done on the root file system (run /sbin/init)
– Initrd file system is removed

File System Types
RAM File Systems - initramfs
●
Abbreviated as initial RAM file system
●
Successor of initrd, with an advantage of flexible size
which can grow and shrink and does not need a driver
●
Gets integrated with kernel image
●
cpio archive of initial file system that gets loaded into
memory during Linux startup process
● Kernel mounts the file system and starts init
●
Faster booting as the it is loaded at boot time, hence
applications can start faster

File System Types
RAM File Systems - initramfs
●
Could be used as intermediate stage before loading real
file system
● The path of file system to be included has to be set while
kernel configuration
● The kernel build process would take care of integrating it
with the kernel image
●
Just search INITRAMFS on the configuration menu to know
where to set the path
●
Just build the kernel once the path is set

File System Types
Disk File Systems

File System Types
Disk (Block) File System
●
Has ability to store data randomly at addresses in a short
amount of time
● Multiple users (or processes) access to various data on the
disk without regard to the sequential location of the data
● Disk file systems are usually block-oriented.
●
Files in a block-oriented file system are sequences of
blocks, often featuring fully random-access read, write,
and modify operations
●
No erasing required before write

File System Types
Disk (Block) File System
●
Examples
– Hard drives, floppys, RAM Disks
– Compact Flash, SD Cards
●
Though this device are based of flash devices, the
integrated controllers take care of the low level
handling of data like block devices

File System Types
Disk (Block) File System - ext2
● Abbreviated as Second Extended File System
●
Matured and stable GNU/Linux file system
●
Does not support journaling support or barriers
●
Not recommend as for / and /home partitions since it take
long time for file system check
●
Most compatible choice for /boot partition
● Recommend for very small partitions (say < 5 MB), because
other file system types need more space for metadata
● Used to be the default file system in several Linux
distribution

File System Types
Disk (Block) File System - ext2
●
ext2 is still preferred choice of flash based storage due
the absence of journal

File System Types
Disk (Block) File System – ext3
●
Abbreviated as Third Extended File System
●
An extension of ext2 with journaling support and write
barriers
●
Backward compatible with ext2 and extremely stable
●
ext2 can be converted to ext3 directly without backup

File System Types
Disk (Block) File System – ext4
● Abbreviated as Fourth Extended File System
● Compatible with both ext2 and ext3 and used as default file
system in many distributions
● Supports huge individual file data and overall file system
size
●
ext4 allows unlimited number of sub directories compared
to ext3
● Has many new features like
– Journal checksum
– Fast fsck etc.
● Can turn off the Journal feature if required

File System Types
Disk (Block) File System - Flash File System
●
Flash file system is designed for storing files on flash
memory–based storage devices
● They are optimized for the nature and characteristics of
flash memory for the following reasons
– Erasing blocks
– Random access
– Wear leveling
●
Examples
– NAND and NOR Flashes
●
In Linux the flash memories use a device file called MTD
for interaction

File System Types
Flash File System - MTD
●
MTD stands form Memory Technology Device
●
Created to have abstraction layer between the hardware
specific device drivers and higher-level applications
●
MTD helps to use the same API with different flash types
and technologies
●
MTD does not deal with block devices like MMC, eMMC,
SD, Compact Flash etc., Since these are no raw flashes
but they have Flash Translation layer. The FTL make these
devices look like block devices

File System Types

File System Types
●
MTD devices can be looked at /proc/mtd
●
Two types of drivers created
– mtdchar drivers
●
Can be seen in /dev as mtd<n> or mtd<n>ro with major
number 90
● Even minor number for rw type and odd minor number for ro
type
– mtdblock drivers
● Can be seen in /dev as mtdblock<n> allowing rw in block
level
● Does not handle bad block check and any wear-leveling

File System Types
●
MTD device are usually partitioned
●
These partitions can be used fro different purposes like
boot code area, kernel image, data partitions etc
●
The MTD partitions can be described by
– Specifying in board device tree
– In kernel code (Hard code)
– Through kernel command line (Modification)
●
Each partition becomes a separate MTD device

File System Types
Flash File System – MTD - Partitions
●
Using Device Tree

File System Types
Flash File System – JFFS2
●
Abbreviated as Journalling Flash File System 2
●
Standard filesystem for MTD flash
●
Compression support for zlib, rubin, rtime and lzo
● Better performance, power down reliability, wear
leveling and ECC

File System Types
Distributed File Systems

File System Types
Distributed File System
●
A network file system is a file system that acts as a client
for a remote file access protocol, providing access to files
on a server.
●
Data accessed by all users can be kept on a central host,
with clients mounting this directory at boot time
●
Data consuming large amounts of disk space may be kept
on a single host

File System Types
Special Purpose File Systems

File System Types
Special Purpose File System
●
Sometimes the way we handle data might depend on the
requirements
● There some file system types which can offer different
features like
– Compressions
– Backups
– Access etc.

File System Types
Special Purpose File System - squashfs
●
Read-only compressed file system for block devices
●
Can be used for read only data like binaries, kernel etc
●
Very good compression rate and read access performance
● Mostly used in live CDs and live USB distros
●
Can support compressions like
– gzip
– LZMA
– LZO etc

File System Partitions
●
Logically dividing the available storage space into
sections that can be accessed independently to one
another for
– File management
– Multiple users
– Data Security
– Efficiency and reliability etc.,
●
Entire storage can be created as a single partition if
required, But multiple partition can help in number of
way like dual or multiboot system, swap etc.

Linux System
●
Two major partitions
– Data partition – Linux data partition
● A root partition and one pr more data partition
– Swap partition - Expansion of physical memory, extra
memory on storage (like virtual RAM)
●
Rarely used in embedded system because of the nature
of the storage devices used

Mount Points
●
All partitions are attached to the system via a Mount
Point
● A mount point defines the place of a particular data set
in a file system
● Usually all the partitions are connected through the root
(/) partition
●
The / will have empty directories which will be the
starting point of partitions
●
Some core partitions can be mounted on startup by
describing it in /etc/fstab

Schemes – Desktop – Example 1
● One possible Desktop
scheme is shown here
● Simplest and standard
one to have
●
Partition for OS which get
mounted as / (root)
● Data partition mounted
as /home
●
Augment to RAM,
referred and mounted as
swap
/
(root)
/home
swap
HardDrive

Schemes - Desktop – Example 2
● Similar to previous
one with a separate
boot partition which
will contain the boot
images
/
(root)
/home
swap
/boot
HardDrive

Schemes - Embedded – Example 1
● The partition scheme
in embedded systems
depends on the
system architecture
● This scheme shows
two stages of boot
loaders each in
different memories
● Rest all the sections
goes in other memory
Bootloader 1
Kernel Image
RFS Image
Bootloader 2
Memory1Memory2Memory3
Data

● This scheme shows
stage 1 of boot loader
in different memory
● Rest all the sections
including stage 2 boot
loader goes in other
memory
Bootloader 1
Kernel Image
RFS Image
Bootloader 2
Memory1Memory2
Data

● This scheme shows all
the contents share in
a single memory Bootloader 1
Kernel Image
RFS Image
Bootloader 2
Memory1
Data

File Systems
Building from scratch
●
File systems can be created manually but
– Would be time consuming
– Lots of dependencies
– Lots of components have to be integrated like binaries,
libraries, scripts, configuration files etc.
– Customization for embedded would be challenging
– Many more..
● So BusyBox is an alternative solution

BusyBox
Introduction
● Often called as the Swiss Army
Knife of Embedded Linux
● BusyBox combines tiny versions of
many common UNIX utilities into a
single small executable
● It provides replacements for most
of the utilities you usually find in
GNU fileutils, shellutils, etc
● Written with size-optimization
and limited resources in mind

BusyBox
Introduction
● The utilities in BusyBox generally have fewer options than
their full-featured GNU cousins; with expected functionality
and behave very much like their GNU counterparts
● Provides a fairly complete environment for any small or
embedded system
● Extremely modular so you can easily include or exclude
commands (or features) at compile time
● This makes it easy to customize your embedded systems
●
Sizes less than < 500 KB (statically compiled with uClibc) or
less than 1 MB (statically compiled with glibc)

BusyBox
Building - Configuration
● Download the latest stable sources from http://busybox.net
● You may try the following targets for configuration
make defconfig
● Configures all options for regular users.
make allnoconfig
●
Unselects all options. Good to configure only what you need.
● Linux kernel like configuration, make menuconfig or make
xconfig also available

BusyBox
● BusyBox, by specifying the cross compiler prefix.
make CROSS_COMPILE=<cross_compile_path>
● cross_compile_path could be the command itself if
already exported in PATH variable, else you can specify the
installation path of command
● For example for arm platform it would look like
make CROSS_COMPILE=arm-linux-
● The cross compiler prefix can be set in configuration interface
if required
BusyBox Setting Build Option Cross Compiler prefix→ →

BusyBox
Installation
● To install BusyBox just type
make install
●
The default installation path would the current directory, will
should see _install directory
● The installation path can be customized in configuration if
required as mentioned below
BusyBox Setting Installation Option BusyBox installation→ →
prefixs
● The installation directory will contain Linux like directory
structure with symbolic links to busybox executable

Embedded Operating System - Linux

In this document

More Related Content

What's hot

Similar to Embedded Operating System - Linux

More from Emertxe Information Technologies Pvt Ltd

Recently uploaded

Embedded Operating System - Linux