Abstract

As we delve into the Raspberry Pi I thought it would be useful to understand how the Linux System boots on this microcontroller. This will help us understand how to make better software choices.

Additionally it will allow a deeper understanding of how the Linux Kernel controls the hardware.

The Linux Boot Process

Before we start on the Raspberry Pi, I thought we would first review how the Linux system boots on a computer. This will give us a basis of comparison when we look at the Raspberry Pi since it has a different boot process.

Which initialization system am I running?

I started exploring my initialization system on this Ubuntu 14.04 system I realized it was not the Traditional Sysvinit system I thought. So I had to find out how to deteremine what I was running.

I found the following commands useful to determine what init command I am using under Ubuntu 14.04 I ran

sudo stat /proc/1/exe

This gave me File: ‘/proc/1/exe’ -> ‘/sbin/init’. But I did not know what init process it was so I ran

/sbin/init --verion

This produced init (upstart 1.12.1). So I knew I was running Upstart.

I then tried finding out what I was using on a Raspberry Pi, by using

sudo stat /proc/1/exe

This time the command returned File: ‘/proc/1/exe’ -> ‘/lib/systemd/systemd’. So I knew I was running SystemD. Next I used another command to find what version I am running.

apt-cache show systemd

Package: systemd

Version: 215-17+deb8u4

Architecture: armhf

Traditional Sysvinit

This graphic is from 6 Stages of Linux Boot Process, which also contains a full explaination of each stage.

Upstart Init

Upstart is revolutionary as it recognises and was designed specifically for a dynamic system. It handles asynchronicity by emitting events. This too is revolutionary.

Upstart emits “events” which services can register an interest in. When an event – or combination of events – is emitted that satisfies some service’s requirements, Upstart will automatically start or stop that service. If multiple jobs have the same “start on” condition, Upstart will start those jobs ‘’in parallel’’. To be manifest: Upstart handles starting the “dependent” services itself - this is not handled by the service file itself as it is with dependency-based systems.

Further, Upstart is being guided by the ultimate arbiter of hardware devices: the kernel.

In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required. Like the best Unix software, it does this job very well. It is efficient, fast, flexible and reliable. It makes use of “helper” daemons (such as the upstart-udev-bridge and the upstart-socket-bridge) to inject new types of events into the system and react to these events. This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered “core” functionality is farmed out to other daemons. Upstart Cookbook

Rationale

The move to the 2.6 kernel and all the “hotplug” goodness that it provides has left us with several problems in dapper. Because the kernel can support hardware coming and going, and due to the increase in removable hardware, it’s no longer possible to guarantee that particular devices are available at a particular point in the boot process.

The usual example is that dapper cannot mount USB disks in /etc/fstab because it is not guaranteed that the block device exists at the point in the mount process where that happens.

Another example is that of a network-mounted /usr; the network device needs to be detected, firmware loaded if necessary, any security layer on the connection negotiated and an IP address arranged before the NFS mount can occur. There are work-arounds to this, such as dapper which sleeps in the boot process until /usr is mounted, but they are hacky and an elegant solution is desired.

There are many other reasons to replace the init system, described in the use cases below. The specified design is intended to be able to fulfil the most important ones for edgy and be extended to support the rest during future release cycles. ReplacementInit

So we are discussing Upstart because this is a more modern process for how to start and control the daemons run by the kernel. It is used on some Linux systems today.

Upstart was an improvement on the System V init expecially for dynamic changes to the system.

Systemd

The way Linux system boots up is quite complex and there have always been need to optimize the way it works. The traditional boot up process of Linux system is mainly handled by the well know init process (also known as SysV init boot system), while there have been identified inefficiencies in the init based boot system, systemd on the other hand is another boot up manager for Linux based systems which claims to overcome the shortcomings of traditional Linux SysV init based system. We will be focusing our discussion on the features and controversies of systemd. Systemd Boot Process a Close Look in Linux

Now I am sure you all understand this? No. Well lets step back and look at a comparison between systemd and sysvinit.

Raspberry Pi boot process

Here are the boot steps from How does Raspberry Pi boot?

When the Raspberry Pi is first turned on, the ARM core is off, and the GPU core is on. At this point the SDRAM is disabled.

The GPU starts executing the first stage bootloader, which is stored in ROM on the SoC. The first stage bootloader reads the SD card, and loads the second stage bootloader (bootcode.bin) into the L2 cache, and runs it.

bootcode.bin enables SDRAM, and reads the third stage bootloader (loader.bin) from the SD card into RAM, and runs it.

loader.bin reads the GPU firmware (start.elf).

start.elf reads config.txt, cmdline.txt and kernel.img

Terms

SoC System on a Chip

ARM Advanced RISC Machine

GPU Graphics Processing Unit

SDRAM Synchronous Dynamic Random-Access Memory

Now that we see how to get up to the Systemd initialization lets have a look at some commands we can execute on systemd to see how it is working.

Awesome ! systemd Commands to Manage Linux System list the commands I am going to try on a raspberry pi.

View a tree of running processes: pstree.

How long to start up: systemd-analyze.

Which services took how long to start: systemd-analyze blame.

What units are running: systemctl list-units.

Which services are running: systemctl list-units -t service.

What is the status of a service: systemctl status udev.

Finally let me give you a couple more links of summary information about systemd.

Question for the Meeting

Where should we go from here. Rather than me try to select the next topic in my crystal ball. How about we try to lay out a path forward. What do you think?

Written by John F. Moore

Last Revised: Wed Oct 18 11:01:24 EDT 2017