Boot

Depends on	Reset

The process of booting a computer encompasses the processes between a reset – for example at ‘power up’ – and the normal operation. When there is an operating system present this will be initialised and started as part of the boot process.

In a simple, embedded controller, all the software may already be present in a non-volatile store (ROM) and the program can just run. In something like a desktop computer, things are more complicated.

A typical boot sequence will ‘chain’ through several stages.

• The first stage can assume very little – for example it does not know anything about files. The RAM – which is usually volatile memory will be undefined; the processor(s) will begin execution from a preset address usually start from a (small, non-volatile) ROM.
  In a desktop (IBM) PC this is the BIOS.
  • This may perform some system tests to check integrity of the memory etc. It will probably see how much RAM is available
  • It will typically have some basic ability to read/execute some code from a backing store such as disk or network.
  • There will probably be some list of potential boot sources – perhaps stored in a small, non-volatile memory. This forms a search path for the next stage of the boot.
    It can be useful to have a path which looks first for some ‘plug-in’ device (such as a DVD) in case the normal boot source (often a hard disk in the box) has been corrupted or failed.
• In an x86 PC (for example) there is a Master Boot Record (MBR) in a known position (the first sector) of a disk. This is read and – if it appears valid – executed. The record is short (512 bytes) so the software here is not very sophisticated!
  Other systems may differ in detail, but the principles still hold.
• A second stage boot loaded may perform more extensive system checks and is capable of loading an operating system.
  • It may give a choice of what to do next to the user.
• A final stage will load and start any operating system(s).
  • This may do additional system tests during initialisation. For example checking out the hardware configuration of the machine to load the relevant device drivers and initialise the appropriate hardware.
  • Finally, it may run an application, such as a shell, window system, etc.

---

Also refer to:	Operating System Concepts, 10th Edition: Chapter 2.9.2, pages 94-95

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Concepts

About this resource • Application Binary Interface (ABI) • Arrays • Atomicity • Boot • Cache • Cacheability • Caching • Concepts • Containers • Context • Context Switching • Deadlock • Direct Memory Access (DMA) • Environment Variables • Exceptions • File Attributes • Fragmentation • Hypervisor • Interrupts • Operation Ordering • PATH • Pointers • Process Scheduling • Processes • Processor Privilege • Queues • Real Time • Reentrancy • Relocatable Code • Spooling and Buffering • Synchronisation • Thrashing • Threads • Virtual Memory • Virtualisation

Articles on Exceptions

Boot • Emulator traps • Errors • Exceptions • Interrupt Controller • Interrupt Service Routines (ISRs) • Interrupts • Memory Fault • Reset • Software Exceptions • System Calls

Articles on User

"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals