Anatomy of the Linux Boot Process

Donna writes "This article discusses detailed similarities and differences involved in booting Linux on an x86-based platform (typically a PC-compatible SBC) and a custom embedded platform based around PowerPC, ARM, and others. It discusses suggested hardware and software designs and highlights the tradeoffs of each. It also describes important design pitfalls and best practices."

Comments

The article:

[killa62]

Contents:
The x86 Linux boot process
The non-x86 Linux boot process
A few alternatives
Summary
Resources
About the author
Rate this article
Related content:
Migrating from x86 to PowerPC, Part 1
Standards and specs: Open Firmware -- the bridge between power-up and OS
Subscriptions:
dW newsletters
Design notes for hardware and firmware involved in booting embedded Linux

Level: Introductory

Lewin Edwards (sysadm@zws.com)
Design Engineer
08 Feb 2005

This installment of "Migrating from x86 to PowerPC" discusses detailed similarities and differences between booting Linux on an x86-based platform (typically a PC-compatible SBC) and a custom embedded platform based around PowerPC, ARM, and others. It discusses suggested hardware and software designs and highlights the tradeoffs of each. It also describes important design pitfalls and best practices.

This article describes the most common traits of embedded Linux(TM) distributions that people employ on x86 hardware and contrasts some of the different options frequently seen on non-x86 embedded systems.

By the time a system has booted itself to the point where it can run your application-level code, any one variant of Linux is, practically by definition, largely similar to another. However, there are several different methodologies that you can use to get the system from power-on reset to a running kernel, and beyond that point, you can construct the filesystem in which your application will run in different ways.

Each approach has its own distinct advantages and disadvantages, and a definite, two-way relationship exists between the hardware you choose to implement and the way you will structure the power-up and Initial Program Load (IPL) process. Understanding the software options available to you is a critical part of the research you must do before designing or selecting hardware.

The x86 Linux boot process
The most fundamental and obvious difference between x86 boards and embedded systems based on PPC, ARM, and others is that the x86 board will ship with one or more layers of manufacturer-supplied "black box" firmware that helps you with power-on initialization and the task of loading the operating system out of secondary storage. This firmware takes the system from a cold start to a known, friendly software environment ready to run your operating system. Figure 1 is a diagram of the typical PC boot process, with considerably more detail than you tend to find in PC-centric literature:

Figure 1. Typical start-up process for x86 Linux
Typical start-up process for x86 Linux

For cost reasons, modern PC mainboard BIOS code is always stored compressed in flash. The only directly executable code in that chip is a tiny boot stub. Therefore, the first task on power-up is to initialize the mainboard chipset enough to get the DRAM controller working so that the main BIOS code can be decompressed out of flash into a mirror area in RAM, referred to as shadow RAM. This area is then write-protected and control is passed to the RAM-resident code. Shadow RAM is permanently stolen by the mainboard chipset; it cannot later be reclaimed by the operating system. For legacy reasons, special hardware mappings are set up so that the shadow RAM areas appear in the CPU's real-mode memory map at the locations where old operating systems like MS-DOS would expect to find them.

Keep in mind that the PC is an open architecture. This openness even extends down to firmware modules within the BIOS itself. Once the power-on initialization (POI) code has run, the next step it takes is to enumerate peripherals, and optionally install hooks provided by expansion ROMs in those peripherals. (Some of those expansion ROMs -- for instance, the video BIOS in a system that has onboard integrated video hardware -- will physically reside in the main BIOS image, but conceptually they are separate entities). The reasons the BIOS has to do this redundant initialization are:

1. Th

Re:The good thing about Linux

[Aadain2001]

Well, you should have checked BEFORE the experiment that your equipment actually supported it. The software may have no issues, but if the mobo and/or card didn't support it, there is nothing the OS can do to keep the magic smoke it :)