Giving Linux the Boot

This session covers all facets of the Linux boot process from power up to
running a user application beginning with ROM boot loader progressing
through secondary program loader, u-boot, kernel and finishing with user-
level initialization.
2
Agenda

• What you will learn

• Overview of the Boot Process
• Boot Modes
• SPL
• U-Boot
• Kernel
• User Level
• Further Reading

3
What You Will Learn
• The elements involved in • Processor initialization
booting into a Linux Kernel
• Read in Linux Kernel
• RBL Stage (ROM Boot
Loader) • Memory Map of boot
• Boot ROM Stage (boot mode process
determination)
• Kernel Stage - Kernel
• SD, NAND, NOR, USB, Initialization
Ethernet, Serial ......
• Init process
• SPL Stage (Secondary
Program Loader) • Memory Map after Linux
• Reads in U-Boot boots
• U-Boot Stage • User login

4
 Go from nothing to Linux OS Environment
•To this full OS

•The different boot stages create

the Linux OS “Stack”
•Boot process enables the Linux
environment of concurrent user
applications, management of HW
peripherals, common services.

•Why are there stages to the

• Starting with bare silicon
boot process????

5
Overview of Any Bootstrap Process

• Basic components to any processor boot –

• Most processors boot through a chained loading method, each step
gains functionality.
• Processor POR jumps to reset vector in ROM after reset line is
released
• ROM Code initializes and reads persistent external storage source for
bootstrap code into memory (maybe internal or external depends on
ROM)
• Processor jumps to load point of read in code, from here it’s the role of
the bootstrap code to continue to perhaps read in more code to stage
the boot process. Or perhaps this bootstrap code is all that is needed to
start intended operation.

6
Why are there Boot Stages?

• At POR the internal ROM code in the processor knows nothing about
the system it is in. Therefore the processor uses pre-defined methods
on where to find the boot code that can be accessed with a minimal
standard configuration of external interfaces.
• The internal RAM is limited in size and due to that only a portion of the
boot process can be read into it. Subsequent stages are enabled from
this partial boot from Internal RAM.
• Biggest reason why is due to system configurations that can only be
defined during the application design process such as memory DDR
types and settings.

7
Linux Boot Process Components
• Components of the Linux Boot Process (Stages)
• RBL – ROM Boot Loader, Contained in the ROM of the Part, minimal
capability to initialize the processor and read in from off chip into
internal RAM the SPL.
• SPL – Secondary Program Loader, called many different names
depending on processor (UBL,Xloader) but is code of a minimal
configuration specific to the target board that has the capability to setup
the processor to be able to read in the next stage which is U-Boot.
• U-boot – Enables most of the specific processor functionality for the
target board and end application to configure the part for booting Linux
and to load the kernel image from persistent storage.
• Kernal image – Final stage of the boot process. Kernel initilization,
MMU enable, Device Initilization, User Init process and finally user level
applications.

8
 4 Stages of the Linux Boot Process
• 4 Stages to Boot Process – ROM, SPL, u-boot, Kernel
• 1 – ROM BL Reads from initialized persistent storage (selected by boot mode)
SPL into internal Ram
• 2 – SPL does additional setup and reads from persistent storage the next stage
u-boot into DDR
• 3 – u-boot continues the processor setup and reads the kernel into DDR
• 4 – Linux boot and initializes user run time environment
Persistent Storage – Readable by ROM
Processor MMC SPL u-boot kernel Root FS
ROM BL 1

Int. RAM 2
This particular SPL
scenario is related This is
to the AM37x discussed
DDR later
U-boot 3

Kernel 4

9
4 Stages of the Linux Boot Process - Cont

• (stage 1) ROM • Each stage adds

functionality.
• (stage 2) UBL/X-loader/U-boot
SPL • Boot mode indicates to the
ROM BL the order of boot
• (stage 3) U-boot modes to try.
• (stage 4) Kernel • ROM BL may indicate to
Processor
SPL where it came from.
Boot Mode ROM BL • While SPL should use the
Selection
Int. RAM same method to find U-
Boot, U-Boot is free to do
-Selects which source of SPL as the user configures. For
-Only used by the ROM BL simplicity here, we assume
it also uses that mode.

10
Overview – Processor Boot Modes
• Boot Modes in TI perspective is strictly related to hardware and about where to read the
next stage in the boot process. This is unrelated to traditional UNIX or Linux runlevels.
• Boot Modes supported vary by device so please consult the data sheet. Typical boot
modes are NAND, I2C, MMC, SPI, Serial, Ethernet.
• Boot mode pins are read and latched once, typically the pins are muxed with another
interface such as the video display lines, input on start and then output after that.
• Each Processor has an app note on this topic

11
Overview – Boot Modes

• Some processors support Boot Sequences based on the Boot Mode.

This allows the ROM code to handle possible failure modes in case the
primary selected persistent storage is not available. Please refer to the
appropriate Data Sheet and Technical Reference Manual (TRM) for the
part.
– AM37x/AM35x/AM387x/AM389x (Sequencing supported, good for sys dev)
– AM18x (Sequencing not supported)

12
Persistent Storage based Boot Modes
• Booting from persistent storage
– This is the most typical workflow.
– Exact location and format of each chunk is media and processor specific
• ROM BL sets requirements for how SPL “looks” so it can tell if it's found a
programmed device or not. Persistent Storage – Readable by ROM
Processor
ROM BL

Int. RAM SPL NAND SPL u-boot kernel Root FS

DDR
MMC SPL u-boot kernel Root FS
U-boot

Kernel SPI SPL u-boot kernel Root FS

I2C SPL u-boot kernel Root FS

13
Connectivity Based Boot Modes
• Booting over Serial Interface
– Typically used for initial programming of persistent storage such as NAND or SPI when other
interfaces aren't available or practical.

• After loading an SPL that sets up DDR a flash tool could be loaded for programming
NAND, SPI, etc.
– In this case the ROM BL will try and initiate a serial download (often X or Y modem based) and if
that succeeds, execute what was downloaded.
• SPL continues to read in next stage (u-boot) over the serial interface
• u-boot may also continue to load the kernel and root filesystem over serial
Host Machine connected over serial cable
Processor
Flash Tool SPL u-boot kernel Root FS
ROM BL 1

Int. RAM 2
SPL
Serial Mode can be used to bring up board initially, albeit
DDR turn around time will be long. < 15 minutes for SPL, u-
Flash tool U-boot boot, kernel and a 10MB root file system.

Kernel

14
But where in memory did it go?

• Processors define a memory map that says where both internal

memory and DDR are mapped to
• SPL, U-Boot and the Linux Kernel are all statically linked to start
running at specific locations within this map.
– Once running they may relocate themselves elsewhere within DDR (once
initialized).
– Different boot modes may require different link addresses.
– For more details about the map for a given processor please refer to the
TRM

15
U-Boot Overview
•Monolithic code image
•Runs processor in physical or a single address space
•Enables clocking, sets up some of the pin mux settings
•Reads in Kernel image (uImage)
•Jumps to load address pointed to in uImage header
•What are environment variables and how are they used
–Default environment variables and how they are used

•Passes Kernel Command Line to Kernel

– ATAGs (Memory, Command Line, etc)
– Flattened Device Trees (FTDs) in the future

•Debugging capabilities (just mentioning, not used during boot process)

16
 U-Boot Environment Variables
U-boot example default u-boot environment print out (printenv)
U-Boot > printenv
baudrate=115200
bootargs=console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait ip=off
bootcmd=if mmc rescan 0; then if fatload mmc 0 0xc0600000 boot.scr; then source
0xc0600000; else fatload mmc 0 0xc0700000 uImage; bootm c0700000; fi; else sf probe 0; sf
read 0xc0700000 0x80000 0x220000; bootm 0xc0700000; fi
bootdelay=3
bootfile="uImage"
ethact=DaVinci-EMAC
stderr=serial
stdin=serial
stdout=serial
ver=U-Boot 2010.12 (Jun 23 2011 - 17:40:56)

• Example printout shows boot arguments and boot command.

• Other u-boot environment definitions telling u-boot what persistent storage to read
for the kernel and what parameters that need to be passed to the kernel and where
to load in memory. Advance knowledge is that the user has to know the kernel load
address and where u-boot is loaded, can use the iminfo command after the uimage
is loaded somewhere in memory, besides on top of u-boot

17
 Kernel uImage – What is it?
U-boot partial console output
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Arago/2.6.37-psp03.21.00.04.sdk/
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2317192 Bytes = 2.2 MiB uImage
Load Address: c0008000 uImage Header Info
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Kernel Image
Starting kernel ...
(Optional
Uncompressing Linux... done, booting the kernel. Compression)

•uImage is a kernel image “wrapped” with a header that describes

among other things load point entry point and whether the kernel is
compressed of not.

•mkimage utility from u-boot is used to make the kernel uImage

during kernel build process

•After the “boot the kernel” message appears on the console u-boot
is no longer used.

18
 Memory Map of Boot Process (AM180x)
Internal RAM
0x80000000
• SPL is loaded into internal RAM SPL

• U-Boot is loaded first into DDR

DDR
• U-Boot then loads the uImage 0xC0000000
from where directed
0xC0008000
• U-Boot performs a checksum and Kernel
then relocates (if required) the
Kernel found in the uImage to the
load address
0xC0700000
• U-Boot then jumps to the entry uImage
address specified in the uImage
header, linux boot starts at this
point
0xC1080000
• Please note the addresses used u-boot
here are for reference only and do
not apply to all devices

19
 Kernel Command Line

• Need to define a few required items such as console port and where
the root filesystem is located. Please note the kernel command line in
the box below. The command line is printed out in the first few lines as
the kernel boots.
Linux version 2.6.37 (jenkins@sdit-build01) (gcc version 4.3.3 (GCC) ) #2 PREEMPT Tue Jul 5 17:47:10
CDT 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA850/OMAP-L138/AM18x EVM
Memory policy: ECC disabled, Data cache writeback
DaVinci da850/omap-l138/am18x variant 0x1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait ip=off

•Optional Command Line

–Specific peripheral initialization

20
 Kernel Command Line NFS example
• NFS boot command line (from below)
–console=ttyS2,115200n8
•Where to send console output and take user input, external serial terminal hooks up to this port
–root=/dev/nfs
•What device interface is the root file system mounted on
–nfsroot=128.247.106.224:/home/user/am180x/rootfs
•Tells the kernel what external host has the Root FS, requires setup on external host
–ip=dhcp
•tells kernel method to configure IP addresses and set up the IP routing table. Here the kernel is being to
use DHCP

Linux version 2.6.37 (jenkins@sdit-build01) (gcc version 4.3.3 (GCC) ) #2 PREEMPT Tue Jul 5 17:47:10 CDT 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA850/OMAP-L138/AM18x EVM
Memory policy: ECC disabled, Data cache writeback
DaVinci da850/omap-l138/am18x variant 0x1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS2,115200n8 root=/dev/nfs rw ip=dhcp nfsroot=128.247.106.224:/home/user/am180x/rootfs

More Info on configuration for NFS can be found here at kernel.org

http://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

21
Overview – Kernel Memory Usage
• Kernel boot process begins DDR
0xC0000000
• Kernel initializes MMU and takes
over DDR. Overwriting anything 0xC0008000
previously there such as u-boot and Kernel
the loaded kernel image.

• Look at virtual memory layout

Linux Mem Mgmt
printed out by kernel

uImage

u-boot

22
Linux Kernel Start

• Performs low level system setup

• Initializes the virtual memory used the kernel and applications
• Perform Device Initialization, interrupt handler setup, Idle Task and the
scheduler

• Calls the init task which sets up user space context

23
 Memory Map from User Application Perspective
System Memory
• Linux creates a virtual memory 0x00000000
space for each user application as
it is loaded. Each User Application
loaded sees a map based from a
start address of 0x00000000.

• User Apps cannot write to

physical addresses listed in the
data sheet such IO ports, EMIF,
or DDR without causing a
segmentation fault. 0x0775d9e0
Space being
• To see how much memory is 0x08000000 used by Kernel
available in a system type free, in this
this is total space of allowed for configuration

executable programs, provided

swap space is disabled.

24
 Virtual Memory Map

• These are components that make

up a virtual memory map system
–CPU/MMU/Memory

• All logical address go through an

MMU to be mapped to a physical
address
• This allows run time link and load
of an application •Want to re-iterate the point of not
writing/reading physical addresses
• Once the processor is running in in the data sheet of the part, this will
a virtual mode, the memory map terminate the application with a
can no longer be considered segmentation fault.
contiguous

Please Note this picture was taken from Wikipedia discussion on virtual memory
http://en.wikipedia.org/wiki/File:MMU_principle.png

25
Linux Virtual Memory (.....Review....)
• Linux memory map
• Total address range supported by the part is no longer relevant, MMU
creates its own memory map
• The actual memory on the board is hidden and managed by the OS virtual
memory manager.
• You can use the /dev/mem interface with the devmem2 application to read and write
physical memory addresses.
• Some drivers may offer an mmap functionality for their buffers and registers as well.

• All apps are compiled to the same starting address

• Linux sets up a process for an app so they all load to same address, this is
possible with an MMU that sets up a virtual memory map
• Every Application sees the same memory map
• Once virtual, the memory can no longer be considered contiguous
meaning a physical addressed DMA cannot be used.

26
 Linux Memory Info Table Dump

• Mem Info Table Dump

• Board has 128MB on it
• Note that the mem total
is less than 128M, this
difference is where the
kernel is stored.
• Only usage described
here and not location in
the virtual memory map

•Link that describes the components of meminfo

–http://www.linuxweblog.com/meminfo

•Google “meminfo explained”

27
 System Physical Memory Map
• The physical memory map that has
been registered on a platform.
• Look at the data sheet for the part and
see how these addresses match up.
–AM1808 Example
•Has a serial interface (UART 1) starting at
0x01d0c000
•Has DDR starting at 0xC0000000
•These are peripherals specific to this particular part.

•Read this article about how to use this

memory interface.
– http://lwn.net/Articles/102232/

•Google “iomem linux explained”

28
Kernel Root File System
• Kernel Must Have a Root File System defined in the kernel command line
• Must be of a certain format in terms of directories contained
• Can be sourced from various device interfaces, examples are:
–RAM Disk : /dev/ram0
–MMC : /dev/mmcblk0p2
–HDA : /dev/hda1
–NFS : /dev/nfs

• Acronyms Explained
–HDA – The master device on the first ATA channel,
–NFS – Network File System
–MMC – This is the MMC/SD interface or Multi-Media Card/Secure Digital

• Link to Overview of Linux Root File Systems

–http://www.linux-arm.org/LinuxFilesystem/WebHome

29
Linux Init Process
• The last step of the Linux Kernel boot process is to call the user space
initilization function “init”
–This is one call of several made by the kernel looking for the user space init function -
run_init_process("/sbin/init"); (in init/main.c)

• Is the first User Space application to run that setups the user environment and
allows user interaction such as login. Below is a ps (process status) dump from
a console, init typically has a PID of 1, first process started.

PID USER VSZ STAT COMMAND

1 root 1616 S init [5]

•/etc/inittab is the script that contains instructions for the init process that
sets up and calls other scripts as part of the user space initialization
–Sets the run level, this in turn sets which init scripts based on run level
are run
–Identifier:RunLevel:Action:Command
–Based on sysv5init scheme

30
 The U-boot bootloader

The U-boot
bootloader

Michael Opdenacker
Thomas Petazzoni
Free Electrons

© Copyright 2004-2009, Free Electrons.

Creative Commons BY-SA 3.0 license
Latest update: 9/9/2016,
Document sources, updates and translations:
http://free-electrons.com/docs/u-boot
Corrections, suggestions, contributions and translations are
welcome!
31
 U-Boot

U-Boot is a typical free software project

Freely available at http://www.denx.de/wiki/U-Boot
Documentation available at http://www.denx.de/wiki/U-
Boot/Documentation
The latest development source code is available in a Git repository:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary
Development and discussions happen around an open mailing-list
http://lists.denx.de/pipermail/u-boot/
Since the end of 2008, it follows a fixed-interval release schedule.
Every two months, a new version is released. Versions are named
YYYY.MM.

32
 Compiling U-Boot (1)

Get the source code from the website, and uncompress it

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 U-Boot features that should be compiled in, etc.
It is a simple .h file that sets pre-processor constants. See the README
file for the documentation of these constants.

Assuming that your board is already supported by U-Boot, there

should be one file corresponding to your board, for example
include/configs/omap2420h4.h.

33
 Compiling U-Boot (2)

U-Boot must be configured before being compiled

make BOARDNAME_config
Where BOARDNAME is the name of the configuration file in
include/configs/, without the .h

Make sure that the cross-compiler is available in PATH

export PATH=/usr/local/uclibc-0.9.29-2/arm/bin/:$PATH

Compile U-Boot, by specifying the cross-compiler prefix.

Example, if your cross-compiler executable is arm-linux-gcc:
make CROSS_COMPILE=arm-linux-

34
 Installing U-Boot

U-Boot must usually be installed in a Flash memory to be executed by

the hardware. Depending on the hardware, the installation of U-Boot is
done in a different way
The board provides some kind of specific boot monitor, which allows to
flash the second stage bootloader. In this case, refer to the board
documentation and tools
U-Boot is already installed, and can be used to Flash a new version of U-
Boot. However, be careful: if the new version of U-Boot doesn't work, the
board is unusable
The board provides a JTAG interface, which allows to write to the Flash
memory remotely, without any system running on the board. It also allows
to rescue a board if the bootloader doesn't work.

35
U-boot prompt

Connect the target to the host through a serial console

Power-up the board. On the serial console, you will see
something like:
U-Boot 1.1.2 (Aug 3 2004 - 17:31:20)
RAM Configuration:
Bank #0: 00000000 8 MB
Flash: 2 MB
In: serial
Out: serial
Err: serial
u-boot #
The U-Boot shell offers a set of commands. We will study the
most important ones, see the documentation for a complete
reference or the help command.

36
Information commands

U-Boot> flinfo
DataFlash:AT45DB021
Nb pages: 1024
Flash Page Size: 264
information Size= 270336 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C0001FFF (RO) Bootstrap
Area 1: C0002000 to C0003FFF Environment
Area 2: C0004000 to C0041FFF (RO) U-Boot
NAND Flash
information U-Boot> nand info
Device 0: NAND 256MiB 3,3V 8-bit, sector size 128 KiB
U-Boot
U-Boot> version
information U-Boot 2009.08 (Nov 15 2009 - 14:48:35)

Can vary from one board to the other

(according to the U-Boot compile
configuration)
37
Environment variables (1)

U-Boot can be configured through environment variables, which affect

the behavior of the different commands.
See the documentation for the complete list of environment variables.
The printenv command also to display all variables or one :
u-boot # printenv
baudrate=19200
ethaddr=00:40:95:36:35:33
netmask=255.255.255.0
ipaddr=10.0.0.11
Network configuration
serverip=10.0.0.1
stdin=serial
stdout=serial
stderr=serial
u-boot # printenv serverip
serverip=10.0.0.2
38
Environment variables (2)

The value of the environment variables can be changed using the

setenv command :
u-boot # setenv serverip 10.0.0.2
Environment variable changes can be stored to flash using the
saveenv command. The location in flash is defined at compile time
in the U-Boot configuration file.
You can even create small scripts stored in environment variables:
setenv mmc-boot 'mmc init 0; if fatload mmc 0 80000000 boot.ini;
then source; else if fatload mmc 0 80000000 uImage; then run mmc-
bootargs; bootm; fi; fi'
You can then execute the script:
run mmc-boot

39
 Transferring files to the target

U-Boot is mostly used to load and boot a kernel image, but it also
allows to change the kernel image and the root filesystem stored in
flash.
Files must be exchanged between the target and the development
workstation. This is possible :
Through the network if the target has an Ethernet connection, and U-Boot
contains a driver for the Ethernet chip. If so, the TFTP protocol can be used
to exchange files
Through the serial line if no Ethernet connection is available.

Target Host
Ethernet connection TFTP
U-Boot TFTP
client server

40
Configuring and testing tftp

On GNU/Linux systems based on Debian: Ubuntu, Knoppix

Install the tftpd-hpa package (tftp server):
apt-get install tftpd-hpa
Copy files to the root directory of the tftp server. Example:
cp arch/arm/boot/uImage /var/lib/tftpboot
To test the server, install a tftp client on your workstation:
apt-get install tftp-hpa
Use it to download a file (-4 to force the use of IPv4)
tftp -4 localhost
> get uImage

41
U-boot mkimage

The kernel image that U-Boot loads and boots must be prepared, so
that an U-Boot specific header is added in front of the image
This is done with a tool that comes in U-Boot, mkimage
Debian / Ubuntu: just install the uboot-mkimage package.
Or, compile it by yourself: simply configure U-Boot for any board of any
architecture and compile it. Then install mkimage:
cp tools/mkimage /usr/local/bin/
The special target uImage of the kernel Makefile can then be used to
generate a kernel image suitable for U-Boot.

42
Flashing a kernel image

Compile your kernel and generate the U-Boot header

running make uImage
Copy the kernel image to the directory exported by the TFTP server
On the board, in U-Boot, download the kernel image to memory :
u-boot # tftp 8000 uImage
Unprotect NOR flash
u-boot # protect off 1:0-4
Erase NOR flash
u-boot # erase 1:0-4
Copy to NOR flash (0x01000000: first sector)
u-boot # cp.b ${fileaddr} 1000000 ${filesize}
Restore NOR flash sector protection:
u-boot # protect on 1:0-4
See our practical labs for details handling NAND flash. 43
boot commands

Specify kernel boot parameters: Continues on

u-boot # setenv bootargs mem=64M \ console=ttyS0,115200the same line
init=/sbin/init \
root=/dev/mtdblock0
Execute the kernel from a given physical address
(RAM or flash):
bootm 0x01030000

44
THANK YOU!

45