An introduction to embedded linux systems for the complete novice.

1. Embedded Linux
Workshop India
Wilson Wingston Sharon
wingston.sharon@gmail.com

2. What are embedded systems?
• Embedded systems are self contained intelligent electronic
control systems.
• They contain a microcontroller / microprocessor and
peripherals interfaced to perform a particular series of tasks.
• Embedded systems today run almost every electronic device
imaginable from TV’s to washing machine.
• Embedded systems also can be used for self-contained
intelligent automated systems.

3. Simple Embedded Example
• An AVR microcontroller. Atmega328.
• Contains all hardware necessary to perform computational tasks
onboard provided power is given to it.
• Communicates with the outside world via gpio pins.
• Can be used to read data from a sensor connected to it and analyze
that. (e.g.: IR
• Can be interfaces to motors and set to control the movement of the
motors depending on the sensor input.
• Then, the microcontroller can be put on-board a bot and be asked to
perform line following!

4. Programming simple MC’s
• Microcontrollers are defined by their architecture and bus bit
width.
• The atmega is an 8 bit AVR series microcontroller.
• To program the atmega we need
• A Compiler to compile C code for the atmega328
• A Flash/EPROM burning device
• The cross compiler convers our code from C to the hex op
code that can be placed in the atmega’s internal memory.
• The atmega executes each instruction sequentially!

5. The problem!
• When we program in native C for a microcontroller, we need to be
intimately aware of the underlying hardware.
• To control the atmega’s behavior we need to engage in register level
programming.
• This makes the code non-portable as the program is now written to
run on only one controller!
• Even different atmega that has different pinouts and register names
will require a complete rewrite of most of the code before the
program can work on it.
• As more advanced microcontrollers / microprocessors emerged into
the market, register level programming needed an alternative to
avoid over specializing developers.

6. Hardware available
• Hardware manufactures keep increasing complexity and
system performance.
• The higher processing power comes with the price of too
much registers with individual internal controlling
methodology
• Hardware manufacturers needed to abstract their hardware to
be able to support easier development.
• Software developers needed a generalized framework where
they cab build their applications without worrying about their
hardware.

7. Hardware v/s software
• Objective : Getting your code to sense / control external devices.
• The more complex your hardware is, the more requirements it will have
in respect to code to write control mechanism.
• If a stand-alone application is required to be developed
• Multiple (internal / external) devices have to be managed in the background
• I/O of different devices must be managed and processed as per demand.
• Interrupts / clocks / power must be managed to keep the microcontroller
running.
• This calls for increased debugging / non portability and results in
increased development time / bugs in the system.
• If hardware is as complicated and powerful as a computer (SBC) then we
need code comparable to that of an Operating System (DOS) to be able
to run it!!

8. Line between HW / SW
• Very few processors can be programmed by flash burning with
ICSP. (e.g: ARM5)
• Modern communication standards are replacing “legacy” RS-
232 with USB, I2C ,Ethernet etc.
• The software control of these protocols in the Atmega register
level way is too complex.
• Harware manufacturers release “Drivers” or libraries for
controlling their hardware to software developers which
allows for more efficient usage of the underlying hardware.

10. Embedded Linux
Hardware Kernel Userland
• Processor • Kernel • This is
• RAM developers where user
• GPIO work on level
hardware application
• Clocks
control of programs
• UART the devices. are written.
• I2C

11. Embedded Linux
• In 1990s, an underground software movement consisting of the
worlds leading developers and programmers wrote a completely
free Operating System!
• As more people used it with the FOSS philosophy, improvements,
fixes and support for multiple processors creeped in!
• This resulted in Linux (the very same kernel ) to run on many
processors and provide a similar level of functionality.
• A Global collaborative effort for improvements and upgrades make
linux so popular with hardware developers
• Most of the time, linux gets fixes and support for new hardware as
soon as they are available!

12. Application Developers
• Embedded developers prefer a non black box OS distribution.
• Although Software application are completely abstracted away
from the hardware, it is still requirement that slight changes /
improvements in the OS code could make the application a lot
more efficiently on the developers embedded target.
• The HAL (Hardware Abstraction Layer) lets you focus on image
recognition and not memory management!
• The Open Source Linux Kernel Project provids a HAL that is
ported to wide range of processors and has driver support for
almost every hardware device in the market.

13. Linux -> Embedded Linux
• Linux for x86 and amd64 (desktop architectures) require
almost 100 - 500mb.
• Embedded Devices have more strict requirements in terms of
memory and processing power.
• Embedded Linux kernels can go as low of 11Mb when placed
in RAM.
• A non distribtion based linux – with only kernel and a minimal
filesystem for a “dos” – like usage is usually run.
• Any custom linux libraries for hardware / software can be
installed to help with application development.

14. Starting the Hardware
• When the hardware is switched on, the OS is present in some
onboard memory peripheral.
• First there is code called a bootloader that initializes all the
required hardware on the board.
• Bootloaders are small programs (4 – 16K) written for and
compiled for specific hardware to be executed immediately
after start.
• The bootloader starts the board and loads the kernel from
where-ever it is into RAM.
• Once the Kernel starts executing from RAM, it takes over and
starts a linux session!

15. Types of Bootloaders
• Intel Motherboard : PHOENIX BIOS :
• This bootloader is present on most intel based laptops.
• It starts the laptop hardware and loads “NTLDR” the windows
bootmanager.
• This code is hardwired into the mother board.
• Embedded Hardware
• Bootloader is usually places in a NAND Flash memory.
• Bootloaders are very small.
• They load, uncompress the linux kernel and relenquish control..

16. Kernel
• Designed as a Finnish UG (B.tech eq) student’s hobby project.
• First was made as a UNIC port for a motorola 64Kb machine that
made Linux designed for Portability.
• The groundwork and FOSS nature allowed the kernel to be ported to
(and thus support) almost every hardware platform on/off the
market.
• The base for extending the kernel through “Device Drivers” have
hardware manufactures / driver developers to release support for
any hardware available.
• Kernel is just a runtime HAL! It just has instructions for running the
hardware – something has to give it instructions -> RootFS..

17. Linux system Design

18. Filesystem (UserLand)
• Filesystem : Collection of directories
• These directories follow a tree heirarchy and contain
• Executable files or programs that the kernel loads into memory
• Libraries for application to link to at run-time
• User Application that can be simply installed onto it
• Setting files that control the Linux OS’s behaviour.
• Hardware devices are also linked as special file nodes in the
filesystem to connect them to the Kernel’s HAL.
• USB drives / HDDs / SD cards are mounted onto the filesystem
and can be browsed as usual.

20. Cross Compilers and
Toolchains
• Different Hardware – Same Source code?
• Cross Compilers are called the translators to machine language for
different architectures.
• Hardware manufactures and developers develop a toolchain for
their architectures.
• The toolchain contain all the utilities required to compile, debug
code and link for the processor.
• There is a GNU toolchain for AVR and ARM architectures.
• The same source code when used with different cross compilers
allow for targeting different platforms.
• The changes in code required for a particular hardware is managed
with localised “patches”.

21. Applications
• Headless units : Devices without the need for a graphical display
• Routers
• Set Top Box
• GUI based Applications
• Touch Smartphones
• GPS car navigation multimedia systems.
• Application developers have:
• System level functionality if required
• Shared libraries for efficient management of resources
• Linux kernel provided complete HAL
• Same code workable of various devices
• Android is a Linux Kernel and FS example!
• Android will run on any phone that linux can work in.
• Phone developers have a unified Free OS to work with.
• Cheaper and more wide variety of applications!

22. Drivers
• Run time modules attached to the linux kernel to manage hardware
peripherals
• USB Wifi
• Camera
• GPS
• Unified driver API that makes it easy to write Driver Code that
integrated to the main Kernel.
• Hardware that is accepted to the main repository (upstream) means
that everybody has access to the driver for that hardware!
• Linux drivers need not be released as source – which means
hardware manufactures can release their driver in binary format.
(becomes proprietary)

23. Libraries
• C library
• Provides an interface to the kenel functions via calls from
userland.
• Stripped down minimal C libraries are there for use in
embedded devices.
• GlibC (Full Featured)
• uCibC (Minimal Variant)
• POSIX support
• Allows for communication job sceduling, multiprocessing and IPC
in a unified framework.
• ALSA
• Advanced Linux Sound Architecture for Hardware DSP support

24. Custom Applications
• Compiled with appropriate cross-compiler as UNIX / POSIX
Compliant applications
• BusyBox
• Provides an embedded shell functionality in embedded devices
• cd ls mkdir echo cat and all standard linux commands all work
• I/O can be managed over a serial line
• Can be thought of as a terminal equivalent
• Commands allow for direct control of the kernel
• Helps navigate the filesystem
• Qt GUI applications can also be built if LCD is present.

25. Run Time Linux
• Serial Console
• Apps that can be autostarted
• Daemons or “services” that provide background application
functionality
• Kernel Threads for Real-Time interrupt management
• RTOS supprt in RT-Linux Project.

26. Memory Considerations
• Linux works primarily on processors with a hardware MMU.
(memory management unit)
• MMU enforces copy and access violation protection in RAM
between kernel, hardware and user application to make sure
system can be kept stable at all times.
• Virtual Memory allows for run-time linking and delinking of un
responsive kernel modules / application to keep the system
functioning even in the event of a crash.

27. Try for yourself
• devmem2
• Memory inspector
• ps
• Running processors
• cat files in /proc
• Gives you current system information

28. Open source Licenses
• Basic funda
• Us at your own Risk
• No guarantee
• We’ll help if we CAN. We don’t need to.
• GPLv2
• GNU Public Licence
• Source must accompany binary
• Linkng to non GPL software not possible.
• LGPL
• Link to non GPL software possible
• To provide for non open source driver development
• LGPL source must be provided
• Modified Free-BSD
• No source delivery required
• For proprietary kernels
• Broken and non FOSS supported Forks