Bios

Inside the Linux boot process
http://140.120.7.20/LinuxRef/BootingLinux/LinuxBo...
BIOS
The BIOS runs off the onboard PROM, EPROM or, most commonly, flash memory when the computer is powered on and it initializes and sometimes performs diagnostic tests on the hard drive, memory, video, chipset and other hardware. Subsequently, it typically decompresses itself from the BIOS memory space into the system main memory and starts executing from there. Nearly all BIOS implementations can optionally execute a setup program interfacing the nonvolatile BIOS memory (CMOS). This memory holds user-customizable configuration data (time, date, hard drive details, etc.) accessed by BIOS code. To find these memory mapped expansion ROMs during boot, PC BIOS implementations scan real memory from 0xC8000 to 0xF0000 on 2 kilobyte boundaries looking for a 0x55 0xaa signature, which is immediately followed by a byte indicating the number of 512 byte blocks the expansion ROM occupies in real memory. The BIOS then jumps to the offset immediately after the size byte, at which point the expansion ROM code takes over and uses BIOS services to provide a user configuration interface, register interrupt vectors for use by post-boot applications, or display diagnostic information. For UNIX and Windows/DOS systems there is a utility with which you can dump your BIOS firmware software at http://www.linuks.mine.nu/ree/
Anatomy of the Linux boot process

Design notes for hardware and firmware involved in booting embedded Linux
Level: Introductory Lewin Edwards, Author, Freelance 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 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
1 of 38
Thursday 21 July 2011 02:48 PM
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
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
2 of 38 Thursday 21 July 2011 02:48 PM
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. The main BIOS itself needs basic console services to announce messages and allow the user to override default start-up behavior and configure systemspecific parameters. 2. Historical issues limit the size of a user-supplied bootloader program to slightly less than 512 bytes. Since this isn't enough space to implement all the possible device drivers that might be required to access different displays and storage devices, it's necessary for the BIOS to install standardized software interfaces for all installed, recognized hardware that might be required by the bootloader. Once all the BIOS-supported system peripherals are initialized, the main BIOS code will run through candidate boot devices (in accordance with a user-configurable preference list) looking for a magic signature word. Storage devices for IBM-compatible PCs have historically used a sector size of 512 bytes, and therefore the BIOS only loads the first 512 bytes from the selected boot device. The operating system's installation program is responsible for storing sufficient code in that zone to bootstrap the remainder of the IPL process. Although it would be possible to write a minimalist Linux bootloader that would fit into such a space, practical Linux bootloaders for the PC consist of two stages: a small stub that lives in the boot sector, and a larger segment that lives somewhere else on the boot medium, usually inside the partition that contains the root filesystem. LILO and grub are the best-known bootloaders for mainstream Linux installations, and SYSLINUX is a popular choice for embedded distributions. Using a RAMdisk The primary purpose of the bootloader is to load the operating system kernel from secondary storage into RAM. In a Linux system (x86 or otherwise), the bootloader can also optionally load an initial RAMdisk image. This is a small filesystem that resides entirely in RAM. It contains a minimal set of modules to get the operating system off the ground before mounting the primary root filesystem. The original design purpose for initial RAMdisk support in the kernel was to provide a means whereby numerous optional device drivers could be made available at boot time (potentially drivers that needed to be loaded before the root filesystem could be
mounted). You can get an idea of the original usage scenario for the RAMdisk by considering a bootable Linux installation CD-ROM. The disk needs to contain drivers for many different hardware types, so that it can boot properly on a wide variety of different systems. However, it's desirable to avoid building an enormous kernel with every single option statically linked (partly for memory space reasons, but also to a lesser degree because some drivers "fight" and shouldn't be loaded simultaneously). The solution to this problem is to link the bare minimum of drivers statically in the kernel, and to build all the remaining drivers as separately loadable modules, which are then placed in the RAMdisk. When the unknown target system is booted, the kernel (or start-up script) mounts the RAMdisk, probes the hardware, and loads only those modules appropriate for the system's current configuration. Having said all that, many embedded Linux applications run entirely out of the initial RAMdisk. As long as you can spare the memory -- 8MB is usually more than enough -- it's a very attractive way of organizing your system. Generally speaking, this is the boot architecture I favor, for a few reasons: 1. The root filesystem is always writeable. It's much less work to have a writeable root than it is to coerce all your other software to put its temporary files in special locations. 2. There is no danger of exhausting flash memory erase-modify-write lifetimes or of corrupting the boot copy of the root filesystem, because the system executes entirely out of a volatile RAM copy. 3. It is easy to perform integrity-checking on the root filesystem at boot time. If you calculate a CRC or other check value when you first install the root filesystem, that same value will be valid on all subsequent boots. 4. (Particularly interesting to applications where the root filesystem is stored in flash) You can compress the boot copy of the root filesystem, and there is no run time performance hit. Although it's possible to run directly out of a compressed filesystem, there's obviously an overhead every time your software needs to access that filesystem. Compressed filesystems also have other annoyances, such as the inability to report free space accurately (since the estimated free space is a function of the anticipated compression ratio of whatever data you plan to write into that space). Other x86 boot considerations Notice a few other points from Figure 1. The first is that the color coding is meaningful. In the blue boxes, the system is running BIOS code and accessing all system resources through BIOS calls. In the green boxes, the system is running user-provided code out of RAM, but all resources are still accessed through BIOS calls. In the yellow boxes, the system is running Linux kernel code out of RAM and operating out of a RAM disk. Hardware is accessed through the Linux device
4 of 38
driver architecture. The purple boxes are like the yellow boxes, except that the system is running out of some kind of secondary storage rather than a RAMdisk. The rules being followed in the gray box are system-specific. You'll observe from this that there are two possible boot routes (actually, more) once the kernel has been loaded. You can load an initial RAMdisk and run entirely out of that, you can use the initial RAMdisk and then switch over to a main root filesystem on some other storage medium, or you can skip the initial RAMdisk altogether and simply tell the kernel to mount a secondary storage device as root. Desktop Linux distributions tend to use the latter design model. Also note that there is an awful lot of redundant code here. The BIOS performs system tests and sets up a fairly complex software environment to make things cozy for operating systems like MS-DOS. The Linux kernel has to duplicate much of the hardware discovery process. As a rule, once the kernel loads, none of the ROM-resident services are used again (although there are some exceptions to this statement), yet you still have to waste a bunch of RAM shadowing that useless BIOS code. The non-x86 Linux boot process In contrast to the x86's complex boot process, an embedded device like the Kuro Box jumps as directly as possible into the operating system. Although there are extant standards for implementing firmware interfaces (equivalent to the PC ROM-BIOS) in PowerPC systems, these standards are rarely implemented in embedded appliances. The general firmware construction in such a system (assuming that it is based on Linux) is that the operating system kernel, a minimal filesystem, and a small bootloader all reside in linearly-accessible flash memory. At power-up, the bootloader initializes the RAM controller and copies the kernel and (usually) the initial RAMdisk into RAM. Flash memory is typically slow and often has a narrower data bus than other memories in the system, so it's practically unheard of to execute the kernel directly out of flash memory, although it's theoretically possible with an uncompressed kernel image. Most bootloaders also give the user some kind of recovery interface, whereby the kernel and initial RAMdisk can be reloaded from some external interface if the flash copies are bad or missing. Off-the-shelf bootloaders used in these applications include blob, U-Boot and RedBoot, although there are others -- and there are many applications that use utterly proprietary bootloaders. Figure 2 illustrates a typical start-up flow for a non-x86 embedded Linux device: Figure 2. Typical start-up process for PPC or ARM Linux
5 of 38
Observe that, as for the x86 startup process above, you have the same possible different routes once the kernel has been loaded. Also note that once control passes to the kernel, the boot process is identical to what it was on the x86. This is to be expected: the further you get in the boot process, the more the software environment is defined by the operating system's API specification rather than the vagaries of the underlying hardware. The layout of flash memory The exact layout of such a system in flash memory depends on two principal factors: the flash device sector size (usually in the neighborhood of 64KB), and the processor's power-on-reset behavior. A core like ARM, which starts execution at address 0, will put the bootloader at the bottom of flash. A core like x86 will need to put the bootloader at the top. There are at least two, and generally four, entities that need to be installed in flash: the bootloader (mandatory), an optional parameter block providing nonvolatile storage for boot options, calibration data and other information, the Linux kernel itself (again, mandatory), and almost always an intial RAMdisk image. For example, a layout for a 4MB flash chip with a 64KB sector size might be as follows: Listing 1. Typical layout of a 4MB flash chip
000000-01FFFF 020000-02FFFF 030000-1FFFFF 200000-3FFFFF Bootloader (128KB) Parameter block (64KB, probably mostly unused) Kernel (1.8MB) Initial RAMdisk image (2MB)
While it is possible to write these various segments across sector boundaries (and it is especially tempting in the case of the parameter block, which will likely be more than 99% empty), this is an extremely unwise practice and should be avoided unless you are under terribly severe flash space constraints. It is particularly vital that the bootloader should reside in a private segment that can be left write-protected. Otherwise, a failed firmware upgrade operation may leave
6 of 38
the system entirely inoperable. Good system engineering should provide a safe fallback position from any possible user-initiated upgrade process. The only part of this software bundle that absolutely must be preloaded at the factory is the bootloader. Once the system is startable from that boot code, you can use other (end-user-accessible) interfaces to load the kernel and RAMdisk image. Why not do this on x86? By the way, at this point the attentive reader may be wondering why embedded PC applications can't use a special boot ROM that simply loads the operating system kernel directly off disk (or some other medium). The answer to this is that while it's possible to write a custom cut-down bootstrap program for a PC motherboard (see, for example, the LinuxBIOS project), the types of applications that use PC hardware tend to be using the board as a black box. Typically, the system integrator will not even have access to datasheets or schematics for the board; they can't write a bootstrap program even if they want to. Furthermore, PC operating systems are built on the assumption that lowestcommon-denominator BIOS services are available, at least at boot time. In other words, it's a simple fact that the path of least resistance is so much easier than a fully custom alternative that practically nobody tries to do it the "smart" way. The inefficiencies of the multi-layer BIOS approach are lost in the noise (as it were) compared with the overall system specifications. Having digested all the above, assuming you understand approximately how large your various software modules will be, you are well prepared to select flash and RAM sizes and layouts for a custom embedded system. Kuro Box happens to use a very uncomplicated memory architecture. It has a single 4MB linear flash chip and 64MB SDRAM. While this is the simplest design, it is not necessarily the cheapest, and you may wish to consider other alternatives if you are designing your own system. A few alternatives One hardware architecture that I have used with some success, and which I have also seen in a few other commercial products, is to use a very small, cheap (generally narrow-bus) OTP EPROM as the primary boot device. This chip is factory-programmed with just enough bootstrap code to load the main firmware image off a secondary storage device and check its integrity. It is very useful if you can also include a little additional intelligence so that the secondary storage device can be reloaded from some external source -- removable media, a serial port, Ethernet, USB or something else -- if the main firmware image becomes corrupted. An attractive choice of storage device for the main image is NAND flash, which is
7 of 38
cheaper than the linear NOR flash used by Kuro Box. NAND flash is produced in vast quantities for removable storage devices: CompactFlash cards, USB "pen disks," Secure Digital (SD) cards, MP3 players, and so on. Although it is possible, with a minimal amount of external logic, to graft NAND flash onto a normal flash/ROM/SRAM controller (such as that in the MPC8241), there are a couple of reasons why you can't simply boot directly out of the NAND flash. The first is that NAND is not guaranteed error-free; it's the host's responsibility to maintain ECC and bad sector mapping information. The second reason is that NAND flash is addressed serially; you send the chip a block number, then read the block out into RAM. Hence, you need a little boot firmware on a normal random-access PROM to do the physical-level management of the NAND. (See Resources for more on NAND and NOR.) Note that some microcontrollers provide hardware NAND controllers that obviate the need for the little boot PROM I discussed above. The disadvantage of relying entirely on that sort of hardware is that you lose the failsafe system-recovery features that can easily be implemented in the boot PROM. However, if you're working against space or cost constraints, and your micro has the NAND control hardware, you may want to avail yourself of it. SoCs sold for cell phone applications use this sort of technology. Summary By now you should understand many of the design choices to be made when building your embedded Linux distribution and selecting the memories in which it will reside and run. You should also understand the way parts of your software distribution can be spread between a RAMdisk and secondary storage devices. The next article gets into the gory details of the software preloaded on the Kuro Box and sets the stage for some real development work. Resources Migrating from x86 to PowerPC is the only developerWorks Power Architecture technology series on the entire Internet that will help you build your own remote-controlled robot submarine army. Missed a previous installment? Don't dismay: it's astonishingly easy to read them all now. Need to hack a serial port onto your Kuro box? Lewin has posted all of the details to his site. Tired of waiting for the BIOS to probe hardware? You may be able to load the kernel directly (developerWorks, May 2004). The LinuxBIOS project is a BIOS replacement for x86 PCs. It directly boots the Linux kernel and requires no secondary storage.
8 of 38
Das U-Boot is a flexible and popular bootloader for numerous different hardware architectures. The blob bootloader (Boot Loader OBject) is a small, easy-to-use bootloader designed for ARM systems. Red Hat's RedBoot bootloader is actually a miniature operating system, based on the eCos product, also from Red Hat. It is very flexible and has been ported to many platforms. This Toshiba presentation describes some of the structure and advantages of NAND flash memories (versus NOR). Red Hat offers a fairly detailed x86-centric description of the Linux start-up and shutdown process. This useful article discusses how to write code that lives in the Master Boot Record (MBR). A recent developerWorks article, Standards and specs: Open Firmware -- the bridge between power-up and OS, covers the Open Firmware boot loader environment (developerWorks, October 2004). IBM has some related material in Linux Handbook: A Guide to IBM Linux Solutions and Resources (IBM Redbook, 2003). Find more Linux-related resources at the IBM developerWorks Linux zone and the developerWorks Linux on Power Architecture Developer's corner. Have experience you'd be willing to share with Power Architecture zone readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside IBM are welcomed. Check out the Power Architecture author FAQ to learn more. Have a question or comment on this story, or on Power Architecture technology in general? Post it in the Power Architecture technical forum or send in a letter to the editors. The Power Architecture Community Newsletter includes full-length articles as well as recent news about members of the Power Architecture community and upcoming events of interest. Subscribe to the newsletter today! All things Power are chronicled in the developerWorks Power Architecture editors' blog, which is just one of many developerWorks blogs.
9 of 38
Find more articles and resources on Power Architecture technology and all things related in the developerWorks Power Architecture technology content area. Download a Power Architecture Pack to demo a SoC in a simulated environment, or just to explore the fully licensed version of Power Architecture technology. This and other fine Power Architecture-related downloads are listed in the developerWorks Power Architecture technology content area's downloads section. About the author Lewin A.R.W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer. Prior to that, he spent five years developing x86, ARM and PA-RISC-based networked multimedia appliances at Digi-Frame Inc. He has extensive experience in encryption and security software and is the author of two books on embedded systems development. He can be reached at sysadm@zws.com.

Take a guided tour from the Master Boot Record to the first user-space application
Level: Introductory M. Tim Jones, Consultant Engineer, Emulex 31 May 2006 The process of booting a Linux system consists of a number of stages. But whether you're booting a standard x86 desktop or a deeply embedded PowerPC target, much of the flow is surprisingly similar. This article explores the Linux boot process from the initial bootstrap to the start of the first user-space application. Along the way, you'll learn about various other boot-related topics such as the boot loaders, kernel decompression, the initial RAM disk, and other elements of Linux boot. In the early days, bootstrapping a computer meant feeding a paper tape containing a boot program or manually loading a boot program using the front panel address/data/control switches. Today's computers are equipped with facilities to simplify the boot process, but that doesn't necessarily make it simple. Let's start with a high-level view of Linux boot so you can see the entire landscape. Then we'll review what's going on at each of the individual steps.
10 of 38
Source references along the way will help you navigate the kernel tree and dig in further. Overview Figure 1 gives you the 20,000-foot view.
Figure 1. The 20,000-foot view of the Linux boot process
When a system is first booted, or is reset, the processor executes code at a well-known location. In a personal computer (PC), this location is in the basic input/output system (BIOS), which is stored in flash memory on the motherboard. The central processing unit (CPU) in an embedded system invokes the reset vector to start a program at a known address in flash/ROM. In either case, the result is the same. Because PCs offer so much flexibility, the BIOS must determine which devices are candidates for boot. We'll look at this in more detail later. When a boot device is found, the first-stage boot loader is loaded into RAM and executed. This boot loader is less than 512 bytes in length (a single sector), and its job is to load the second-stage boot loader.
Linux i386 Boot Code HOWTO or (Original Copy)

When the second-stage boot loader is in RAM and executing, a splash screen is commonly displayed, and Linux and an optional initial RAM disk (temporary root file system) are loaded into memory. When the images are loaded, the second-stage boot loader passes control to the kernel image and the kernel is decompressed and initialized. At this stage, the second-stage boot loader checks the system hardware, enumerates the attached hardware devices, mounts the root
11 of 38
device, and then loads the necessary kernel modules. When complete, the first user-space program (init) starts, and high-level system initialization is performed. That's Linux boot in a nutshell. Now let's dig in a little further and explore some of the details of the Linux boot process. System startup The system startup stage depends on the hardware that Linux is being booted on. On an embedded platform, a bootstrap environment is used when the system is powered on, or reset. Examples include U-Boot, RedBoot, and MicroMonitor from Lucent. Embedded platforms are commonly shipped with a boot monitor. These programs reside in special region of flash memory on the target hardware and provide the means to download a Linux kernel image into flash memory and subsequently execute it. In addition to having the ability to store and boot a Linux image, these boot monitors perform some level of system test and hardware initialization. In an embedded target, these boot monitors commonly cover both the first- and second-stage boot loaders. In a PC, booting Linux begins in the BIOS Extracting the MBR at address 0xFFFF0. The first step of the BIOS is the power-on self test (POST). The To see the contents of your MBR, use job of the POST is to perform a check of this command: the hardware. The second step of the $ sudo dd if=/dev/hda of=mbr.bin bs=512 count=1 BIOS is local device enumeration and $ od -xa mbr.bin | tee /tmp/mbr.txt initialization. $ od -xa /boot/grub/stage1| tee /tmp/stage1.txt Given the different uses of BIOS functions, the BIOS is made up of two parts: the POST code and runtime services. After the POST is complete, it is flushed from memory, but the BIOS runtime services remain and are available to the target operating system. To boot an operating system, the BIOS runtime searches for devices that are both active and bootable in the order of preference defined by the complementary metal oxide semiconductor (CMOS) settings. A boot device can be a floppy disk, a CD-ROM, a partition on a hard disk, a device on the network, or even a USB flash memory stick.
$ diff /tmp/mbr.txt /tmp/stage1.txt
The dd command, which needs to be run from root, reads the first 512 bytes from /dev/hda (the first Integrated Drive Electronics, or IDE drive) and writes them to the mbr.bin file. The od command prints the binary file in hex and ASCII formats. This MBR sector is installed by the setup command of GRUB by combining stage1 and address of stage2 boot loader together. From the output of diff command, you see the majority of contents are the same. Grub Install manual page has more details.
Commonly, Linux is booted from a hard disk, where the Master Boot Record (MBR) contains the primary boot loader. The
MBR is a 512-byte sector, located in the first sector on the disk (sector 1 of cylinder 0, head 0). After the MBR is loaded into RAM, the BIOS yields control to it. Stage 1 boot loader The primary boot loader that resides in the MBR is a 512-byte image containing both program code and a small partition table (see Figure 2). The first 446 bytes are the primary boot loader, which contains both executable code and error message text. The next sixty-four bytes are the partition table, which contains a record for each of four partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the magic number (0xAA55). The magic number serves as a validation check of the MBR. The How Master Boot Record (MBR) Works: article describes it in more details. Figure 2. Anatomy of the MBR
The job of the primary boot loader is to find and load the secondary boot loader (stage 2). It does this by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they're all inactive. When this is verified, the active partition's boot record is read from the device into RAM and executed.
Stage 2 boot loader The secondary, or second-stage, boot loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk. The first- and second-stage boot loaders combined are called Linux Loader (LILO) or GRand Unified Bootloader (GRUB) in the x86 PC environment. Because LILO has some disadvantages that were corrected in GRUB, let's look into GRUB. (See many additional resources on GRUB, LILO, and related topics in the Resources section later in this article.) GRUB stage boot loaders The /boot/grub directory contains the stage1, stage1.5, and stage2 boot loaders, as well as a number of alternate loaders (E.g., CR-ROMs use the iso9660_stage_1_5).
The great thing about GRUB is that it includes knowledge of Linux file systems. Instead of using raw sectors on the disk, as LILO does, GRUB can load a Linux kernel from an ext2 or ext3 file system. It does this by making the two-stage boot loader into a three-stage boot loader. Stage 1 (MBR) boots a stage 1.5 boot loader that understands the particular file system containing the Linux kernel image. Examples include reiserfs_stage1_5 (to load from a Reiser journaling file system) or e2fs_stage1_5 (to load from an ext2 or ext3 file system). When the stage 1.5 boot loader is loaded and running, the stage 2 boot loader can be loaded. With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a command-line shell for greater manual control over the boot process. With the second-stage boot loader in memory, the file system is consulted, and the default kernel image and initrd image are loaded into memory. With the images ready, the stage 2 boot loader invokes the kernel image. Kernel With the kernel image in memory and Manual boot in GRUB control given from the stage 2 boot loader, the kernel stage begins. The From the GRUB command-line, you can kernel image isn't so much an boot a specific kernel with a named executable kernel, but a compressed initrd image as follows: kernel image. Typically this is a zImage (compressed image, less than 512KB) or grub> kernel a bzImage (big compressed image, /bzImage-2.6.14.2 greater than 512KB), that has been [Linux-bzImage, setup=0x1400, size=0x29672e] previously compressed with zlib. At the
head of this kernel image is a routine that does some minimal amount of grub> initrd /initrd-2.6.14.2.img hardware setup and then decompresses [Linux-initrd @ 0x5f13000, 0xcc199 bytes] the kernel contained within the kernel image and places it into high memory. If grub> boot an initial RAM disk image is present, Uncompressing Linux... Ok, booting the kernel. this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins. If you don't know the name of the kernel to boot, just type a forward slash When the bzImage (for an i386 image) is (/) and press the Tab key. GRUB will invoked, you begin at setup.S (not ./arch display the list of kernels and initrd /x86_64/boot/head.S, I believe!) in the start images. assembly routine (see Figure 3 for the major flow). This routine does some basic hardware setup and invokes (through code32_start label, see Document for code32_start) the startup_32 routine implemented in ./arch/x86_64/boot/compressed/head.S. This startup_32 routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). The kernel is then decompressed through a call to the C function decompress_kernel (located in ./arch/x86_64/boot/compressed/misc.c). When the kernel is decompressed into memory, it is executed. There is yet another startup_32 function, but this function is defined in ./arch/x86_64/kernel/head.S. And in the entrance of this function, the CPU is already in 32-bit protected mode. The next two items are extracted from linuxgazette.net, here is the Original Copy. 1. The startup_32( ) function - 1st function. What does it do? Okay, let's get to the confusing point straight away. There exist two functions called startup_32(). Although both these two startup_32() functions are assembly language functions and are required for "bootstrap" process, they are totally different functions. The one we refer to here is coded in arch/i386 /boot/compressed/head.S file. After setup() code is executed, the function has been moved either to physical address 0x00100000 or to physical address 0x00001000, depending on whether the Kernel Image was loaded "high" or "low" in RAM. This function when executes, performs the following operations: 1. The segmentation registers are initialized along with a provisional stack. 2. The area of uninitialized data of the Kernel is filled with zeroes. It is identified by symbols _edata and _end. 3. It then executes a function decompress_kernel( ). This function is used to decompress the Linux Kernel image. As a result, the "Uncompressing Linux ..." message is displayed on the screen. After the Linux Kernel
image has been decompressed correctly, the "OK, booting the kernel." message is shown. One very significant question here is: Okay, we understand the Linux Kernel image is decompressed. But, where is it loaded? The answer is: If the Linux Kernel image was loaded "low", then the decompressed kernel is placed at physical address 0x00100000. Otherwise, if the Linux Kernel image was loaded "high", the decompressed kernel is placed in a temporary buffer located after the compressed image. The decompressed kernel image is then finally moved to its final position, which starts at physical address 0x00100000. 4. Finally code execution jumps to the physical address 0x00100000. Now, after the 4th operation (as mentioned above is over), code execution is taken over by the other startup_32() function. In other words, the second one takes over the bootstrapping process. 2. The startup_32() function - 2nd function. What does it do? The decompressed Linux kernel image begins with another startup_32( ) function. This function exists in /usr/src/linux-2.4.2/arch/i386/kernel/head.S file. The question that must come up here is: Hey, using two different functions having the same name... Doesn't this cause problem? The answer is: Well, no it doesn't at all. Cause both functions are executed by jumping to their initial physical addresses and hence they are executed in their own execution environments. No problem at all! Now, let's look at the second startup_32( ) function functionality. What does it do? This function when executes, it essentially sets up the execution environment for the first Linux process (process 0). The function performs the following operations: 1. The segmentation registers are initialized with their final values. 2. Sets up the Kernel Mode stack for process 0. 3. It then invokes and executes a function setup_idt() that fills the IDT (Interrupt Descriptor Table) with null interrupt handlers. 4. The system parameters obtained from BIOS is put in the first page frame. 5. The "Model" of the processor is identified. 6. Loads the gdtr and idtr registers with the addresses of the GDT and IDT tables. 7. It finally makes a jump to the start_kernel() function. Two startup_32() functions originally from linuxdevcenter
16 of 38
Renaissance: The two startup_32( ) functions

There are two different startup_32( ) functions; the first one is coded in the arch/i386/boot/compressed/head.S file. After setup() terminates, the function has been moved either to physical address 0x00100000 or to physical address 0x00001000, depending on whether the kernel image was loaded high or low in RAM. This function performs the following operations: 1. Initializes the segmentation registers and a provisional stack. 2. Fills the area of uninitialized data of the kernel identified by the _edata and _end symbols with zeros. 3. Invokes the decompress_kernel( ) function to decompress the kernel image. The "Uncompressing Linux ... " message is displayed first. After the kernel image has been decompressed, the "O K, booting the kernel" message is shown. If the kernel image was loaded low, the decompressed kernel is placed at physical address 0x00100000. Otherwise, if the kernel image was loaded high, the decompressed kernel is placed in a temporary buffer located after the compressed image. The decompressed image is then moved into its final position, which starts at physical address 0x00100000. 4. Jumps to physical address 0x00100000. The decompressed kernel image begins with another startup_32( ) function included in the arch/i386/kernel/head.S file. Using the same name for both the functions does not create any problems (besides confusing our readers), since both functions are executed by jumping to their initial physical addresses. The second startup_32( ) function essentially sets up the execution environment for the first Linux process (process 0). The function performs the following operations: 1. 2. 3. 4. Initializes the segmentation registers with their final values. Sets up the kernel mode stack for process 0. Invokes setup_idt( ) to fill the IDT with null interrupt handlers. Puts the system parameters obtained from the BIOS and the parameters passed to the operating system into the first page frame. 5. Identifies the model of the processor. 6. Loads the gdtr and idtr registers with the addresses of the GDT and IDT tables. 7. Jumps to the start_kernel( ) function.
startup_32
This
takes over the second stage of system booting:
1. Calling x86_64_start_kernel, 2. This, in turn, calls start_kernel, 3. At the end of start_kernel, rest_init is called
17 of 38
4. And then rest_init starts a kernel thread executing the init function defined at the end of the init/main.c file. 5. At the end of this init function, /sbin/init is executed and this is the forever running init process in the system.
/* Something wrong in the following assertions. Probably the */ /* last one. But, I copy it from the original source file! */ init->smp_init->cpu_up: All in init/main.c cpu_up->__cpu_up: in kernel/cpu.c __cpu_up->do_boot_cpu->setup_trampoline: in arch/x86_64/kernel/smpboot.c setup_trampoline->memcpy(tramp, trampoline_data, trampoline_end - trampoline_data): in setup_trampoline trampoline_data: jumps to startup_32 in arch/x86_64/kernel/head.S: in arch/x86_64/kernel/trampoline.S
In the new startup_32 function (also called the swapper or process 0), the page tables are initialized and memory paging is enabled. The type of CPU is detected along with any optional floating-point unit (FPU) and stored away for later use. The x86_64_start_kernel, implemented in arch/x86_64/kernel/head64.c file, (which calls start_kernel) function is then invoked (start_kernel implemented in init/main.c), which takes you to the non-architecture specific Linux kernel. This is, in essence, the main function for the Linux kernel. The output of dmesg command at this point starts to reflect the whole booting process. For example, the BIOS-provided physical RAM map: string is printed by setup_memory_region. In turn, this function is called from setup_arch and setup_arch is invoked in start_kernel.
Figure 3. Major functions flow for the Linux kernel i386 boot
With the call to
start_kernel,
a long list of initialization functions are called to set up
18 of 38
interrupts, perform further memory configuration, and load the initial RAM disk. In the end, a call is made to kernel_thread (implemented in arch/x86_64/kernel/entry.S) to start the init function, which is the first user-space process. Finally, the idle task is started and the scheduler can now take control (after the call to cpu_idle). This cpu_idle function is running forever and it calls schedule() periodically. With interrupts enabled, the pre-emptive scheduler periodically takes control to provide multitasking. During the boot of the kernel, the initial-RAM disk ( initrd) that was loaded into memory by the stage 2 boot loader is copied into RAM and mounted. This initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted. Reference for ramfs, rootfs and initramfs: Document For ramfs, initramfs, etc. The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS). Init After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library. Prior to this point in the process, no standard C applications have been executed. In a desktop Linux system, the first application started is commonly /sbin/init. But it need not be. Rarely do embedded systems require the extensive initialization provided by init (as configured through /etc/inittab). In many cases, you can invoke a simple shell script that starts the necessary embedded applications. Summary decompress_kernel output The decompress_kernel function is where you see the usual decompression messages emitted to the display:
Uncompressing Linux... Ok, booting the kernel.
19 of 38
Much like Linux itself, the Linux boot process is highly flexible, supporting a huge number of processors and hardware platforms. In the beginning, the loadlin boot loader provided a simple way to boot Linux without any frills. The LILO boot loader expanded the boot capabilities, but lacked any file system awareness. The latest generation of boot loaders, such as GRUB, permits Linux to boot from a range of file systems (from Minix to Reiser). Resources Learn Boot Records Revealed is a great resource on MBRs and the various boot loaders. This resource not only disassembles MBRs, but also discusses GRUB, LILO, and the various Windows boot loaders. Check out the Disk Geometry page to understand disks and their geometries. You'll find an interesting summary of disk attributes. A live CD is an operating system that's bootable from a CD or DVD without needing a hard drive. "Boot loader showdown: Getting to know LILO and GRUB" (developerWorks, August 2005) gives you a detailed look at the LILO and GRUB boot loaders. In the Linux Professional Institute (LPI) exam prep series of developerWorks tutorials, get a comprehensive introduction to booting a Linux system and many other fundamental Linux tasks while you prepare for system administrator certification. LILO was the precursor to GRUB, but you can still find it booting Linux. The mkintrd command is used to create an initial RAM disk image. This command is useful for building an initial root file system for boot configuration that allows preloading of block devices needed to access the real root file system. At the Debian Linux Kernel Project, find more information on the Linux kernel, boot, and embedded development. In the developerWorks Linux zone, find more resources for Linux developers. Stay current with developerWorks technical events and Webcasts. Get products and technologies
20 of 38
The MicroMonitor provides a boot environment for a variety of small target devices. You can use this monitor to boot Linux in an embedded environment. It has ports for ARM, XScale, MIPS, PowerPC, Coldfire, and Hitachi's Super-H. GNU GRUB is a boot shell filled with options and flexibility. LinuxBIOS is a BIOS replacement. Not only does it boot Linux, LinuxBIOS, itself, is a compressed Linux kernel. OpenBIOS is another portable BIOS project that operates on a variety of architectures such as x86, Alpha, and AMD64. At kernel.org, grab the latest kernel tree. Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2, Lotus, Rational, Tivoli, and WebSphere. With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
Discuss Check out developerWorks blogs and get involved in the developerWorks community. About the author: M. Tim Jones M. Tim Jones is an embedded software architect and the author of GNU/Linux Application Programming, AI Application Programming, and BSD Sockets Programming from a Multilanguage Perspective. His engineering background ranges from the development of kernels for geosynchronous spacecraft to embedded systems architecture and networking protocols development. Tim is a Consultant Engineer for Emulex Corp. in Longmont, Colorado.
Getting to know LILO and GRUB

Boot loader showdown: Getting to know LILO and GRUB
Contrast and compare these two contenders
21 of 38
Most Linux users, from the casual desktop user to the Linux system administrator, have used a utility known as a boot loader. Different variations of this utility provide varying levels of support and functionality. In many cases, the default boot loader installed with a Linux distribution is not always the best for your needs; the same can be said for the default settings of each boot loader. In this article, Laurence Bonney discusses the pros and cons of two of the more popular boot loaders -- LILO and GRUB -- and suggests a number of configurations to get the most from your machine. What utility do practically all Linux users use -- regardless of their job or expertise? A boot loader. In this article, see how a boot loader works, meet two popular loaders -- LILO (LInux LOader) and GNU GRUB (GRand Unified Boot loader) -- and review the pros and cons of each. What is a boot loader? Most simply, a boot loader loads the operating system. When your machine loads its operating system, the BIOS reads the first 512 bytes of your bootable media (which is known as the master boot record , or MBR). You can store the boot record of only one operating system in a single MBR, so a problem becomes apparent when you require multiple operating systems. Hence the need for more flexible boot loaders. The master boot record itself holds two things -- either some of or all of the boot loader program and the partition table (which holds information regarding how the rest of the media is split up into partitions). When the BIOS loads, it looks for data stored in the first sector of the hard drive, the MBR; using the data stored in the MBR, the BIOS activates the boot loader. Due to the very small amount of data the BIOS can access, most boot loaders load in two stages. In the first stage of the boot, the BIOS loads a part of the boot loader known as the initial program loader, or IPL. The IPL interrogates the partition table and subsequently is able to load data wherever it may exist on the various media. This action is used initially to locate the second stage boot loader, which holds the remainder of the loader. The second stage boot loader is the real meat of the boot loader; many consider it the only real part of the boot loader. This contains the more disk-intensive parts of the loader, such as user interfaces and kernel loaders. These user interfaces can range from a simple command line to the all-singing, all-dancing GUIs. Boot loaders are usually configured in one of two ways: either as a primary boot loader or as a secondary boot loader. Primary boot loaders are where the first stage of the boot loader is installed on the MBR (per the previous description). Secondary boot loaders are where the first stage of the boot loader is installed onto a bootable partition. A separate boot loader must then be installed into the
MBR and configured to pass control to the secondary boot loader. Many newer Linux boot loaders can be especially useful since they give you varying degrees of interaction, such as advanced GUI and encrypted passwords, along with the ability to load from a selection of operating systems. Thus you can have many operating systems coexisting on the same machine spanning multiple physical disks. This setup has become common because it helps many users reconcile the treasures of valuable datafiles originally generated by their Windows machines with their shiny new Linux installs. Personally, I think this setup is great; I use a single box for both Linux and Windows. Over time, boot loaders have been enhanced to include a greater range of functionality for the user. Such functionality and configuration vary from loader to loader, although the basic purpose remains the same. Now let's look at two of the more popular boot loaders: LILO and GRUB. LILO
LInux LOader, or LILO, comes as standard on all distributions of Linux. As one of the older/oldest Linux boot loaders, its continued strong Linux community support has enabled it to evolve over time and stay viable as a usable modern-day boot loader. Some new functionality includes an enhanced user interface and exploitation of new BIOS functions that eliminate the old 1024-cylinder limit.
Although LILO continues to be developed, the basic principles of how LILO works still remain the same. Making LILO your boot loader What you will need to do to use LILO as your boot loader depends on whether you are installing the OS fresh or have already installed Linux and are planning on moving to LILO. If you're starting fresh, you can jump straight to the Configuring LILO section. If you already have a Linux distribution installed, you usually get an option to install and configure LILO (and can boot your machine into your new Linux install). For existing Linux users migrating to LILO, first you have to acquire the latest version of LILO (see Resources). Before doing anything else, I advise you to make sure you have a Linux boot disk handy -- it makes life a lot easier if you accidentally mess something up and would like to be able to get back into your original Linux configuration! Once you have LILO on your system, making it take over your MBR is very easy. As the root user, type:
# /sbin/lilo -v -v
This will use the current LILO defaults and splat anything that is currently in the MBR. However, read about Configuring LILO to make sure you are able to boot up
as expected. Also note that if you want to run Windows and Linux on a single machine, you should install your Windows OS first and then the Linux OS, so that the boot loader you choose in the Linux install won't be written over by the Windows boot loader. Unlike the Linux boot loaders, the majority of Windows boot loaders will not allow you to load Linux. If you've already installed Linux first, don't fret; just create yourself a Linux boot disk so that after you have installed Windows, you can get back into your Linux install and overwrite the MBR. Configuring LILO LILO configuration is all done through a configuration file located in /etc/lilo.conf. Listing 1 shows an example configuration, relating to my home machine, for dual booting a Linux and Windows machine. You can visualize how this configuration relates to an actual machine by looking at my basic workstation setup: Primary HDD (physical disk 1) with Windows XP installed (initially all there was on the machine). In Linux terms, this HDD is /dev/hda (hd0,0 in GRUB terms). Secondary HDD (physical disk 2) with Red Hat Linux installed; the root partition is on the third partition of this hard drive, /dev/hdb3 (hd1,2 in GRUB terms). Listing 1. Example lilo.conf file
boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=100 compact default=Linux image=/boot/vmlinuz-2.4.18-14 label=Linux root=/dev/hdb3 read-only password=linux other=/dev/hda label=WindowsXP
The options used in Listing 1 are: The boot= line tells LILO where to install the boot loader. In the previous example, this will install it to the MBR of first hard disk. You could alternatively install LILO in /dev/hdb3 (the Linux partition in the example), which would then require you to install another boot loader into /dev/hda
that points it to the LILO boot loader; then you just let LILO act as a secondary boot loader. In general, /dev/hda is the most common place for your boot loader to reside. You can also make a LILO floppy boot disk by pointing this parameter to the floppy drive, most commonly /dev/fd0. map= points to the map file used by LILO internally during bootup. When you install LILO using the /sbin/lilo command, it automatically generates this file, which holds the descriptor table (among other things). My advice is to leave this as it is! install= is one of the files used internally by LILO during the boot process. This holds both the primary and secondary parts of the boot loader. A segment of this boot.b file is written to the MBR (the primary part of the boot loader), which then points to the map and subsequently points to the secondary boot loader. Again, leave this as it is! prompt= tells LILO to use the user interface (giving you in this example two selections -- Linux and WindowsXP). In addition using the prompt/user interface, you get the option to specify specific parameters for the Linux kernel or others if appropriate. If you do not specify this option in the configuration file, LILO will boot into the default OS with no user interaction and no waiting. (It's worth noting, though, that if you hold the SHIFT key down during boot, you can get the prompt up anyway, which is quite useful if you don't want the average Joe to be exposed to the boot loader). timeout= is the number of tenths of a second that the boot prompt will wait before automatically loading the default OS, in this case Linux. If prompt is not specified in the lilo.conf, this parameter is ignored. The compact option magically makes the boot process quicker by merging adjacent disk read requests into a single request. It can be a mixed blessing, though, as I've seen a number of posts on forums regarding issues with this option. This option especially useful if you wish to boot from a floppy. The default= option tells LILO which image to boot from by default, such as after the timeout period. This relates to a label of one of the images in the lilo.conf file. If you don't specify this option in the configuration file, it will boot the first image specified in the file. For each version of Linux you want to make available for users to boot into, you should specify image= and the following three options. The image option specifies the kernel version you wish to boot to. label= identifies the different OS you want to boot from at the user interface at runtime. In addition, this label is used for specifying the default OS to boot from. (Note: Avoid spaces in the label name; otherwise, you will get an unexpected error when loading the file.) The root= option tells LILO where the OS file system actually lives. In our example, it is /dev/hdb3, which is the third partition of the second disk. read-only tells LILO to perform the initial boot to the file system read only. Once the OS is fully booted, it is mounted read-write. The password= option allows you to set a password for the specific OS you are booting into. In the example this password is held in the lilo.conf file as
25 of 38
readable text, so is easily accessible for all to read. Alternatively if you set password="" you can set the password when the bootloader is installed. These can be set on each of the operating systems you wish to boot from if required (in our example we only set a password on the Linux boot). other= acts like a combination of the image and root options, but for operating systems other than Linux. In our example, it tells LILO where to find the Windows OS, which resides on the first disk in the first partition. This will usually be the case if you have installed Windows first, then Linux. label= is the same as all other label options. You can use many other parameters in the lilo.conf file, but the parameters in Listing 1 should get you into a fairly usable state on your machine. For further information on these and other lilo.conf parameters, refer to the manual pages (man lilo.conf). Since lilo.conf is not read at boot time, the MBR needs to be "refreshed" when this is changed. If you do not do this upon rebooting, none of your changes to lilo.conf will be reflected at startup. Like getting LILO into the MBR in the first place, you need to run:
$ /sbin/lilo -v -v
The -v -v flags give you very verbose output. There are a fair number of parameters you can specify when running LILO like we did. See the manual pages for further information (man lilo). The initial boot process When LILO initially loads, it brings up in order each of the letters -- L-I-L-O. If all the letters come up, the first stage boot was successful. Anything less indicates a problem: L: The first stage boot loader has been loaded. If LILO stops here, there were problems loading the second stage boot loader. This is usually accompanied by an error code. The common problems at this stage are media problems or incorrect disk parameters specified in your lilo.conf file. LI: The second stage boot loader has been loaded. LILO halting at this point indicates the second stage boot loader could not be executed. Again, this can be due to problems similar to just L: loading or if the boot.b file has been corrupted, moved, or deleted. LIL: The second stage boot loader has now been executed. At this point, media problem could again be responsible or the map file (as specified in the lilo.conf file) could have had problems finding the descriptor tables. LIL?: Loaded to the same point as above. This usually means the second stage boot loader loaded at an incorrect address, caused most likely by boot.b being in a different place than specified in the lilo.conf file. LIL-: Loaded to the same point as above. Problem loading the descriptor table, most likely due to a corrupt descriptor table. LILO: LILO has successfully loaded with no errors.
Additional configuration at boot time Once LILO has successfully loaded, you will see a LILO prompt. Still using the example lilo.conf file as before, at this point you have two choices, which may not be immediately obvious to LILO newbies. First, you may let LILO time out (after 10 seconds), which will boot /dev/hdb3, the Linux partition. Second, you can press the TAB key, which will list a selection of operating systems to boot from. In our example lilo.conf, we would get "Linux" and "WindowsXP" as our options. Typing either of these will load up that OS. Specifically loading the Linux option will then prompt you to enter a password, which in this case is linux. Incorrectly entering the password will take you back to the LILO prompt. A final word of advice when trying out LILO for the first time: I found it a lot safer to work out my LILO configuration using a floppy boot disk rather than my hard disk. To do this, you must replace the boot=/dev/hda with boot=/dev/fd0 in the lilo.conf file. That way, if I messed up any of the configuration in my lilo.conf file, I could take out the boot disk and boot into Linux as before. Once I was happy everything booted fine using the floppy disk, I then changed my lilo.conf back to use boot=/dev/hda and ran /sbin/lilo a final time to upload my changes. GNU GRUB More recently, the GRand Unified Boot loader (commonly known as GRUB) seems to have somewhat taken the boot loaders crown from LILO. GNU GRUB is actively developed by the Free Software Foundation and based on the original GRUB program, originally created by Erich Stefan Boleyn. Make GRUB your boot loader As with LILO, the steps you will need to perform to use GRUB as your active boot loader depend on whether you are installing the OS fresh or have already installed Linux and are planning on moving to GRUB. If you're starting fresh, you can jump straight to the Configuring GRUB section. If you already have a Linux distribution installed, you usually get an option to install and configure LILO (and can boot your machine into your new Linux install). For existing Linux users wanting to migrate to GRUB, get the latest version of GRUB (see Resources). Again, as with LILO, before doing anything else, have a Linux boot disk handy. With the interactive mode (described below), this disk should not be required, but it's nice to have just in case you get out of your depth. Once you have GRUB installed on your system, making it take over your MBR is easy. As the root user, type:
# /boot/grub/grub
This will load up a BASH-like command prompt where you now use the GRUB command:
27 of 38
grub> install (hd1,2)/boot/grub/stage1 (hd1) (hd1,2)/boot/grub/stage2 p (hd1,2)/boot/grub/menu.conf
This command uses the GRUB install command, which requires the location of the stage one image and the location of the MBR ( install (hd1,2)/boot/grub/stage1 (hd1)). Also the location of the stage two image ((hd1,2)/boot/grub/stage2) is required. Finally, an optional p (hd1,2)/boot/grub/menu.conf tells GRUB the location of the GUI menu configuration file. In the previous example, hd1 is my Linux Disk and hd0 is my Windows disk. This will use the current GRUB defaults and splat anything that is currently in the MBR (read Configuring GRUB to make sure you are able to boot up as expected). Configuring GRUB GRUB configuration is all done through a configuration file located in /boot/grub /grub.conf. Listing 2 shows an example configuration that relates to my home setup, a dual-booting Linux and Windows machine: Listing 2. Example grub.conf file
default=0 timeout=10 splashimage=(hd1,2)/grub/splash.xpm.gz password --md5 $1$opeVt0$Y.br.18LyAasRsGdSKLYlp1 title Red Hat Linux password --md5 $1$0peVt0$Y.br.18LyAasRsGdSKLYlp1 root (hd1,2) kernel /vmlinuz-2.4.18-14 ro root=LABEL=/ initrd /initrd-2.4.18-14.img title Windows XP password --md5 $1$0peVt0$Y.br.18LyAasRsGdSKLYlp1 rootnoverify (hd0,0) chainloader +1
The options used in Listing 2 are: The default= option signals to GRUB which image to boot from by default after the timeout period. This relates to one of the images in the grub.conf file. 0 is the first specified, 1 is the second specified, etc. If you don't specify this option in the configuration file, it will boot the first image specified in the file. timeout= is the number of seconds the boot prompt will wait before automatically loading the default OS, in this case, Red Hat Linux. splashimage= is the location of the image to be used as the background for the GRUB GUI.
28 of 38
The password option specifies the MD5-encrypted password used to gain access to GRUB's interactive boot options. Note this does not stop users loading your defined OS choices; this needs to be set on a per-title basis. To generate an md5 password, run the tool grub-md5-crypt (as root), which comes with GRUB. It will prompt you for the password you want to encrypt. It then will output the MD5-encrypted password. Copy this into your grub.conf after password -md5 but on the same line. Usually this password can be set to the root password, since it is only root who can read the grub.conf file anyway. title identifies the specific OS that will be booted from at the user interface at runtime. Unlike with LILO, you can include spaces in this name. password is set in the same way as the password above. Do not set this password to the root password if you are planning on sharing this machine with other users. The root option tells GRUB where the OS file system actually lives. As you can see, GRUB references the media in a different way than LILO. In our LILO example, /dev/hdb3 is the third partition of the second disk. Grub references this disk as (hd1,2), again the third partition of the second disk (disk 0 being the first disk, partition 0 being the first partition). kernel: vmlinuz-X.X.XX-XX is the name of the default boot kernel image within your root directory. initrd: initrd-X.X.XX-XX.img is the name of the default initrd file within your root directory. title is the same as all other title options. password: See other password options. The rootnoverify option tells GRUB to not try to vary the root of the OS. This saves load errors if the file system is not a supported by GRUB. chainloader +1 tells GRUB to use a chain loader to load this OS, which is required for loading Windows. You can use many other parameters in the grub.conf file, but the parameters in Listing 2 should get you into a fairly usable state on your machine. For further information on these and other grub.conf parameters, see the manual pages (man grub.conf). Unlike LILO's configuration file, grub.conf is read at boot time, and the MBR does not need to be refreshed when this is changed. The initial boot process When GRUB initially loads, like LILO it loads its first stage from the MBR. Once this has loaded, it then enters an intermediate stage between the common boot loader stages one and two (or for argument's sake, Stage 1.5). Stage 1.5 is present to enable regular file system access to the GRUB configuration files in /boot/grub rather than accessing using disk blocks. We then enter stage two of the boot loader where GRUB loads the grub.conf file.
29 of 38
You should now see the GRUB GUI. For any native Windows user, this seems a much more friendly experience than that of LILO. But don't think by having a GUI that GRUB is a dumbed-down boot loader. The wealth of options is astonishing. (See the tips for additional configuration at boot time.) If your configuration is like mine, you should now be looking at a screen giving you two options: to boot into Red Hat Linux or to boot into Windows XP. By default, it will load Linux. The result of selecting either one of these is self explanatory. Now for the good stuff. Additional configuration at boot time At the GRUB GUI, pressing any key will stop the timeout from kicking in. Then by pressing the P key, you can enter your GRUB password and gain full access to GRUB's interactive booting options. You should now be able to use one of the three options by pressing the one of the following keys: For edit commands before booting, press E. This allows you to edit the specific options for the currently highlighted OS. GRUB will then show only the options specific to the booting of that OS, which you can then edit as you see fit. This is especially useful if you have specified the wrong HDD for the root file system. If you need to access the machine in single-user mode (giving you root access without specifying a password!), select the Linux OS at the GRUB main screen. Then as before, press E and move to the kernel line (in my example, this is kernel /vmlinuz-2.4.18-14 ro root=LABEL=/). You then append single to the end of this line, and press B to boot using your changed grub.conf. Any changes you make in edit mode are not saved to the grub.conf file. To modify kernel arguments, press A. If you are an experienced Linux user, you can tweak the kernel arguments to suit your needs. To get to a BASH-like command-line interface, press C. This minimal command-line interface allows you to find GRUB configuration files on your system, load an alternate configuration file, and edit lines in the configuration file, as well as enter GRUB commands directly. You might use this if a configuration change, such as deleting a partition, has made your system unbootable. You might also use it if you need to boot a system into single-user mode or perhaps runlevel 3 instead of your normal runlevel. The many uses for these options are beyond the scope of this article. As you can see, GRUB really opens up the possibilities at boot time. This can be a mixed blessing, though, as GRUB also potentially allows attackers to gain access to the system before the OS has loaded. The main areas open to misuse are: Access to single-user mode. Anyone loading into single-user mode is given
30 of 38
root access, leaving your Linux system wide open to abuse. Access to other operating systems. Any bootable operating systems you have configured that do not require a password, such as DOS, will be open. Access to the GRUB editor. This allows users full access to change the GRUB configuration. Setting security plays an important part in your GRUB configuration; setting a password and using MD5 encryption pays dividends to your overall system security. Future of GRUB GRUB is now being replaced by GRUB2. The original GRUB is being renamed to GRUB Legacy; apart from fixing bugs, it will no longer be actively developed. GRUB2 will be a complete rewrite of the original boot loader. To date, the following features are the core of the changes: Replacement of Stage 1.5 with the creation of a compact core image Support for dynamic loading to the core image Trend towards making the overall GRUB framework object oriented Support for internationalization, such as non-ASCII character sets Support for different hardware architectures and different platforms (other than Linux) Refer to the GRUB Web site (see the Resources section below for the latest developments. GRUB vs. LILO As stated at the start of this article, all boot loaders work in a similar way to fulfill a common purpose. But LILO and GRUB do have a number of differences: LILO has no interactive command interface, whereas GRUB does. LILO does not support booting from a network, whereas GRUB does. LILO stores information regarding the location of the operating systems it can to load physically on the MBR. If you change your LILO config file, you have to rewrite the LILO stage one boot loader to the MBR. Compared with GRUB, this is a much more risky option since a misconfigured MBR could leave the system unbootable. With GRUB, if the configuration file is configured incorrectly, it will simply default to the GRUB command-line interface. Conclusion As with all software, the best choice for one user isn't always the best for all. Of the two boot loaders covered here, my personal favorite is GNU GRUB. It is a good all-around loader, combining a slick user interface with a wealth of
31 of 38
functionality. And yet many people who have used and loved LILO still find it to be the boot loader of choice. Fortunately, if you are new to the world of Linux boot loading, you won't go far wrong with either. Regarding security, anyone with access to a boot disk/CD can get past any of the security measures mentioned in this article by simply booting using a grub.conf or lilo.conf that does not have security set. With GRUB in particular, being able to boot into single-user mode could pose a serious security hole. A simple way to get around this problem is to disable booting from CD and floppy in your machine's BIOS and make sure your BIOS is set with a password so others can not change these settings. Have fun! Resources Learn The tutorial "Getting to know GRUB" (developerWorks, January 2001) shows how to install and use GRUB. The tutorial "Build a Linux test network" (developerWorks, May 2003) shows how to combine Samba and GRUB to build a compact, highly adaptable, cross-platform test network, capable of booting and networking a large number of operating systems on a small number of machines. "Boot Linux from a FireWire device" (developerWorks, July 2004) explains how to boot Linux from a removable drive (breathing new life into old machines). "Tip: Dual-booting Linux" (developerWorks, April 2002) explains how to install multiple instances of Linux on a single box. "Lightweight Linux, Part 1" (developerWorks, October 2002) shows you how to build LILO. Find more resources for Linux developers in the developerWorks Linux zone.
Get products and technologies Pick up the latest LILO. Get the latest version of the GRUB boot loader, and take a look at GRUB2 as well.
32 of 38
Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2, Lotus, Rational, Tivoli, and WebSphere. Build your next development project on Linux with IBM trial software, available for download directly from developerWorks.
Discuss Get involved in the developerWorks community by participating in developerWorks blogs. About the author Laurence Bonney is a software engineer at IBM Hursley Labs in the United Kingdom. He works as the Technical Team Leader of the test team working on the IBM WebSphere MQ JMS product. In his spare time he plays guitar (badly), goes surfing as much as his vacation will allow, and plays video games. You can reach Laurence at bonneyl@uk.ibm.com.
Booting Linux
1. Introduction
"Booting the computer", this is a common word associated with starting the computer. Though we use it casually in our daily life, have you ever thought of what exactly it is ? or how the system brings itself to a workable environment ? Well, my attempt in this article is to explain all the stages involved in booting your linux machine. In simple words, "bootstrapping" means starting up your computer. It involves all those stages, from the moment you power on your machine till the system is ready to log you in.
2. The Boot Process

The Boot process involves several different stages that the system undergoes while it is being booted. If any of these stages fail, then the system cannot start itself. * The BIOS
33 of 38
* * * * *
Kernel Initialization Hardware Configuration System Processes Startup Scripts Multiuser Mode
Lets look at each of the above stages in detail. 2.1 The BIOS This is the initial stage of the boot process. The moment you power your system, the microprocesser is not aware of your computer environment or even your operating system. It is the BIOS, that provides the necessary instructions to microprocessor and helps to initialize the computer environment. That is why it is called Basic Input/Output System. These are the main tasks of BIOS. * POST (Power On Self Test): The BIOS performs a power on self test on all hardware components attached to the computer during booting. You might have noticed the LEDs on your keyboard flashing during booting. That is an example of POST. If anything fails, it will be reported to you on your screen. * The BIOS provides a set of low level routines for the hardware components to interface with the Operating System. These routines act like drivers for your Screen, Keyboard, Ports etc. * The BIOS helps to manage the settings of hard disks, your first boot device, system time and more. The BIOS also initiates the bootstrapping sequence by loading the Initial Program Loader (The boot loader program) into the computer memory. The software is usually stored in the ROM. This stage is actually outside of the domain of the Operating System and it is more vendor specific. 2.2 Kernel Initialization Linux actually implements a two stage boot process. In the first stage, the BIOS loads the boot program (Initial Program Loader) from the hard disk to the memory. In the second stage, the boot program loads the Operating System kernel vmlinuz into memory. Though, the kernel can be called any name, we'll call it vmlinuz. Well, it's just a tradition, where 'vm' stands for the Virtual Memory support and last 'z' denotes that it is a compressed image, ie vmlinux.z => vmlinuz. When the kernel loads into memory, it performs a memory test. Most of the kernel
34 of 38
data structures are initialized statically. So it sets aside a part of memory for kernel use. This part of the memory cannot be used by any other processes. It also reports the total amount of physical memory available and sets aside those for the user processes.
2.3 Hardware Configuration

If you have configured a linux kernel, you would have configured the hardware sections as well. This is how the kernel knows what hardware to find. Based on the configuration, when the kernel boots, it tries to locate or configure those devices. It also prints the information of the devices it found during the bootup. It will probe the the bus for devices or asks the driver for information of the devices. Devices that are not present in the system or not responding to the probing will be disabled. It is possible to add more devices using the util 'kudzu'.
2.4 System Processes Once the hardware initialization is complete, the kernel will create several spontaneous processes in the user space. The following are those processes. * * * * * init keventd kswapd kupdated bdflush
These are called spontaneous processes because they are not created by the usual fork mechanism. Of these, only 'init' is actually in the user space(only processes in the user space can be controlled by us) , we have no control over others. The rest of the boot up procedure is controlled by init.
2.5 Startup Scripts Before explaining how startup scripts work, let's have a look at the tasks performed by them. The following are the important tasks performed by startup scripts. * * * * * * Set the name of the computer Set the time zone Check the hard disk with fsck Mount system disk Remove old files from /tmp partition Configure network interfaces with correct IP address
35 of 38
* Startup deamons and other network services The startup scripts are found in /etc/rc.d/init.d folder in your linux machine. 1. 2.5.1 Init and runlevels You can boot your linux machine to different runlevels. A runlevel is a software defined configuration of your system where the system behaviour will vary in different runlevels. Though, linux can have 10 different runlevels, only 7 of them are used. I have mentioned them below.
description runlevel 0 1 or S 2 3 4 5 6 shutdown single user mode multiuser mode without nfs full multiuser mode not used X windows reboot
You can specify the runlevel in the init configuration file /etc/inittab. 2. 2.5.2 Startup Scripts and runlevels You may see folders (rc[0-7].d) corresponding to each runlevel in the /etc folder. These folders contain files symbolically linked (in linux everything is a file) to the startup scripts in folder /etc/rc.d/init.d. If you look at these folders, you may see that the name of the symbolic links starts with the letter "S" or "K" followed by a number and the name of the startup script /service to which it is linked to. For example, the following are the files in runlevel 2 and 3. /etc/rc2.d/K20nfs -> ../init.d/nfs /etc/rc2.d/S55named -> ../init.d/named The name of those files are important. Because when you switch between runlevels, the services are started/stopped based on these names. Consider these two cases here.
* switching to higher runlevels - init will run scripts that start with letter S, in ascending order of the number with argument 'start' * switching to lower runlevels - init will run scripts that start with letter K, in decending order of the number with argument 'stop' The runlevels init checks to switch between them, depends on the configuration of your system. The following commands will help. For more details of the commands, refer to the manual pages. The commands that deal with runlevels are: /sbin/runlevel - shows the previous and current runlevels /sbin/init and /sbin/telinit - to switch between runlevels /sbin/chkconfig - to enable/disable services in runlevels 3. 2.5.3 Startup Scripts and /etc/sysconfig files The files in the /etc/sysconfig folder are read by the startup scripts. So it's worth mentioning them here.
* network - contains information of your hostname, nisdomain name etc. * clock - timezone information * autofsck - automatic filesystem check during boot up * network-scripts - folder contains interface configuration files ifcfg-lo, ifcfg-eth0 etc. * hwconf - hardware information * sendmail, spamassassin, syslog, yppasswdd - information about the corresponding daemons. Edit the files in /etc/sysconfig folder to make changes to your system.
4. 2.5.4 Init and single user mode This runlevel is used by sysadmins to perform routine maintenance. Its most commonly used for checking errors in file system with command 'fsck'. Only the root file system will be mounted in this runlevel and the system administrator is provided with a shell. If necessary, other partitions needs to be mounted manually. Also none of the deamons will be running in this runlevel. Only the system administrator can use the system in this mode. You can simply exit from the shell to boot it to the multiuser mode. 2.6 Multiuser Operation Though the system has been booted to a particular runlevel, none of the users can
login to the system until init spawns getty processes on terminals. If the system is booted to runlevel 5, init needs to spawn the graphical login system 'gdm'. If the system has gone through the above mentioned stages without any failures, you may say that your system is booted and is ready to perform the tasks :)
3. Rebooting and Shutting down

We have discussed about the boot procedure so far. It is also important to shutdown the system properly. Otherwise you may end up with loss of data or serious damage to the file system. You can safely use the commands /sbin/shutdown, /usr/bin/halt or /usr/bin/reboot to halt or reboot the computer. For more details of the commands, refer to the manual pages. For more information about GRUB, you may trace the next link: GRUB Tutorial
38 of 38

Bios

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bios

Uploaded by

Copyright:

Available Formats

Inside the Linux boot process

Anatomy of the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Inside the Linux boot process

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Figure 1. The 20,000-foot view of the Linux boot process

Linux i386 Boot Code HOWTO or (Original Copy)

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Inside the Linux boot process

Inside the Linux boot process

Inside the Linux boot process

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Renaissance: The two startup_32( ) functions

takes over the second stage of system booting:

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

With the call to

a long list of initialization functions are called to set up

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Getting to know LILO and GRUB

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Inside the Linux boot process

Inside the Linux boot process

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

grub> install (hd1,2)/boot/grub/stage1 (hd1) (hd1,2)/boot/grub/stage2 p (hd1,2)/boot/grub/menu.conf

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process

Thursday 21 July 2011 02:48 PM

Inside the Linux boot process