BUILDING AND PORTING
EMBEDDED OPERATING
SYSTEMS
Dif ference
between
booting a PC or
an Embedded
System
THE BOOTING PROCESS
Power
On
PC
Embedded
BIOS
X-Loader
Get Bootloader
Get Bootloader
GRUB
U-Boot
Get Kernel
Kernel
Power
On
Get Kernel
Kernel
EMBEDDED SYSTEM VS PC
 PCs are a highly modular platform. Most components are in
sockets or slots that permits easy replacement.
 Embedded Systems tend to solder their components directly
to the PCB as they don’t need to be replaced.
EMBEDDED SYSTEM VS PC
i7-930
i7-920
i7-940
i7-950
i7-965X
i7-960
i7-970
i7-980X
EMBEDDED SYSTEM VS PC
EMBEDDED SYSTEM VS PC
EMBEDDED SYSTEM VS PC
USB 2.0
USB 3.0
Intel PCH
Gigabit Ethernet
7.1 Audio Codec
S-ATA
3 & 6Gbps
IDE & Floppy
EMBEDDED SYSTEM VS PC
TI OMAP 3730 Processor
512MB DDR@200MHz
PowerVR SGX530 Graphics
All soldered directly to the
board. Not intended for
replacements.
EMBEDDED SYSTEM VS PC
 PC booting is a much
longer process than
x86 Desktop
for embedded
systems.
x86 Laptop
 Desktop PCs are by far
the worst due to their
BCM97425
massive compatibility
issue
Raspberry Pi
 Laptops are faster
because their
IGEPv2
components are much
more controlled.
Time to Linux
Kernel
Prompt
Time to
Bootloader
Time to POST
0
20
40
Desktop PC: Gigabyte GA-X58A-UD3R, Intel Core i7-950 @ 4.2GHz, 12GB DDR3-1600, GeForce GTX580, Crucial M4 256GB SSD
Laptop PC: Dell XPS 15 L502x, Intel Core i7-2670QM @ 2.2GHz, 6GB DDR3-1600, Intel HD3000 & GeForce GT540M, Western Digital Caviar Black 750GB.
BUILDING AND PORTING
EMBEDDED OPERATING
SYSTEMS
BIOS and
Bootloaders
BIOS
• BIOS stands for Basic Input Output System
• First performs Power on self test and initializes Memory, PCI bus, Video, storage,
Network(PXE), HID and any other systems a bootloader may need to load the OS.
• Allows user to choose hardware settings within a simple UI
• X86 always starts CPU in real mode.
• 20 bit segmented memory address space
• Only 1 MiB of addressable memory.
BIOS
BIOS
•
Post POST search for a bootable drive and copy 512byte MBR to RAM.
•
This 512bytes is the MBR
• Partition table 64b
• Two byte boot signature
• Optional Disk timestamps and signatures
• First stage Bootstrap code takes up the rest
•
The BIOS yields control to the bootstrap who's only task is to locate and execute a more
complex second stage bootloader (grub,BOOTMGR,NTLDR)
Bootloader
What is a bootloader?
• Program used to load an operating system or another boot loader.
• Boot loaders run in Real mode and use BIOS provided code
• Operating systems replace BIOS code with their own.
What is a second stage bootloader?
• Programs like GRUB, LILO or NTLDR
• allow multi-boot systems
• They are aware of file systems
• Allow creation of ram discs in memory to boot the linux kernel
• Once the kernel has retrieved all the information it requires in Real mode it will change the cpu
to protected mode providing support for virtual memory, memory protection, multitasking and
code privilege levels.
UEFI – The Future?
What is it?
• Unified Extensible Firmware Interface
•
Replacement for BIOS
Improvements
• Not a single piece of firmware but a programmable software
interface.
•
It is hardware independent
•
It provides a standard method of interfacing with firmware
during the boot process
•
It's faster due to using Block I/O over interrupts
UEFI – The Future?
•
64bit version can address all system memory while booting.
•
Can boot from disks larger than 2TB
•
Pre-boot networking support
•
Mouse usable in boot options
•
You can mount partitions and read file systems
•
Doesn't solve the problem of requiring two drivers. One for the firmware and one for the
operating system.
•
Secure Boot(arguably)
BUILDING AND PORTING
EMBEDDED OPERATING
SYSTEMS
IGEPv2
framework
IGEP boot process
ROM Code
X-Loader
U-Boot
Kernel
ROM Code
What does the IGEP ROM code do?
• Code is executed in a known location in ROM
• Minimal Configuration is performed
• Some clocks set
• Some memories and peripherals initialised
•
Searches boot devices for suitable boot image
•
Supports serial, SD card, NAND flash and USB amongst others.
•
Boot order is defined by a set of GPIO configuration pins referred to as SYSBOOT
•
On finding the first x-loader image it is copied to SRAM and then executed
ROM Code
Serial Boot
• ID is written out to the serial port and a response is waited for.
• If response received within time limit ROM will transfer data received from serial port to SRAM and execute
it.
SD Boot
• The ROM code looks for a suitably formatted SD card on the MMC controllers.
If a readable partition is found directory is scanned for a specially signed file called an "MLO" . Assuming the
file is as expected, it is transferred into the internal SRAM and control is passed to it.
NAND\eMMC
• If NAND is in the boot list the ROM code will attempt to load the first sector, skipping it if its bad, corrupt or
blank. If it reaches the 4th sector and no good sector has been found it will move on. If a good sector is
found then it will load the contents to ram and then start executing it.
X-loader
What is x-loader?
• X-loader is a first stage boot-loader that implements a subset of the features of u-boot.
• It's small enough to fit in on-chip memory but still provides the ability to configure the pin muxing, clocks,
serial console and DDR access to load the fully featured u-boot into the second stage boot loader.
• In IGEP a copy of the x-loader is part of the NAND
• Not limited to 512bytes
MLO files
• Through MLO files the need for a second stage boot loader can be removed.
• An MLO file is a an x-loader file that has been given a header with the size of the image and deployment
memory location.
• You can optionally define clock frequency amongst other things
• MLO files allow zImages to be booted without the need for a second stage boot loader
Serial and SD
• X-loader supports transfering an image to the board using kermit over a serial connection and will also
load a uboot.bin file stored on the SD.
Watch out!
Boot-loaders are doing configuration that the
kernel is not!
JTAG
• Initially devised for testing printed circuit boards with its boundary scanning
functionality JTAG is now used extensively for debugging, programming CPLDS
and initialising flash memory.
• Can be useful to recover bricked devices or write new firmware to NAND on
restricted devices. But the IGEP is un-brickable
• Tools like OpenOCD and GDB ARM have successfully been used on OMAP530
devices like the beagleboard.
BUILDING AND PORTING
EMBEDDED OPERATING
SYSTEMS
Das U-Boot
BUILDING AND PORTING
EMBEDDED OPERATING
SYSTEMS
OS/Bootloader
Coupling in:
QNX?
 QNX is a Canadian microkernel -based RTOS.
 Device drivers are all run as userspace applications outside the
kernel.
 Used in many applications, mainly automotive systems.
 HAM (High Availability Manager).
 Adaptive Partitioning Scheduler.
 Safety critical certification.
 QNX owned by RIM.
 Tightly coupled bootloader and kernel.
 Transparent distributed networking.
BOOTLOADER/OS INTERACTION
 Most general purpose operating systems (such as linux) avoid
becoming too tightly coupled with their bootloaders.
 This has led to bootloaders which support a multitude of
functions.
 An RTOS developer can take advantage of this by using the
generic bootloader (and it’s more advanced capabilities (NFS,
ping) to ensure hardware works, and easily bring it to life.
 During development this general purpose bootloader can be
effectively used as a “bootloader loader”.
 The high-functionality (and easy to hack!) bootloader (i.e. U-Boot)
can then be removed from a shipped product, leaving behind only
a basic tightly -coupled version.
QNX BOOTING
U-Boot
IPL
Startup
QNX
Kernel
 On-Chip boot ROM code generally causes the CPU
to perform minimal initialisation of peripheral
such as NAND Flash and instructs it to begin
reading code from there into memory and
executing it.
 This code can be a standard embedded bootloader
such as U-Boot, or it can be a QNX IPL.
 U-Boot loads the QNX “IPL” image into memory,
and begins executing it.
 The “IPL” is an “Initial Program Loader” which is
responsible for initialising basic hardware and
passing control to “Startup” code, and
subsequently the QNX Kernel.
QNX IPL








CODE
Begins in assembly, performs initialisation for HLL.
Initialises CPU/(some) Peripheral Clocks.
Initialises basic I/O (serial).
Minimal pin multiplexing for required peripherals (i.e. SDHC
hardware).
Reads in and decompresses “IFS” image ( ramdisk + kernel).
Includes basic (FAT) filesystem drivers for SDHC reading.
Passes control to “Startup”
Can start “minidrivers” for device interaction before
OS/Kernel even begins booting.
CODE
QNX STARTUP
 Startup begins in C language, initialises most peripherals, and
sets up important kernel structures.
 The QNX kernel expects a “ syspage” structure to exist at a pre defined location in memory. This structures provides
important information about the host system.
 Enables CPU SMP operation (multiple -cores).
 Often re-does initialisation done by IPL (such as serial I/O) to
enable more advanced functionality.
 Informs minidrivers of new environment before passing
control to kernel.
CODE
SYSPAGE
 Indicates CPU type (e.g. ARM) and vital information (e.g.
number of cores), and other supported features such as NEON
extensions.
 Provides access to hardware -specific function callouts made
available to the system before the Kernel was running.
 Provides information about the memory environment in which
the kernel is running.
 Information about bus devices, IRQs.
 Information about connected peripherals and device trees for
/dev population.
MINIDRIVERS
 Prevents need for auxillary processors for instant -on
peripheral ineraction.
 Linked against bootloader code.
 Called periodically during startup, initially with polling and
then interrupts when they become available.
 Full drivers are allowed access to minidriver memory once the
kernel has loaded so they can take over without data loss.
 Make use of I/O hardware within 10ms of power -on.
SUMMARY
 QNX Implements its own FS -aware bootloader (IPL).
 This bootloader is tightly coupled with its own system
initialisation and kernel.
 This bootloader is only configurable via source code, unlike U Boot or Grub.
 Source code for bootloader and startup is freely available for
a variety of hardware (kernel is not):
 http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp
/wiki/BSPAndDrivers
 Questions?