Port Linux OS (LInux Kernel) to Your own Mobile

Is it possible? Well, depends on maaany IFs. Here are the most of them “briefly”..First of all, you have to be crazy enough to wanting to port Linux on a mobile phone, on which no-one else had tried before. 

Linux kernel is a piece of code, and every mobile phone is a little clone of somewhat that resembles to an old IBM PC (or Mac or Solaris etc.) which is capable of executing pieces of code (that’s why your mobile phone works..)

Running Linux successfully on the phone depends on how openly the phone’s manufacturer has architectured it.

In the worst case, on your chosen mobile you can execute at a low-level in kernel-mode a piece of code to sum two numbers on the processor once you power on your gadget; but you’ll never be able to observe it, because neither keypad nor screen would work nor anything else would work!

Putting it in a very simple words: If all specifications are closed, and you still want Linux on your precious handy, you would have to collect all the drivers from every chip inside your phone (by unscrewing and googling what’s written on a chip on the board) and/or reverse engineer and write drivers on your own, then put everything together and have a Linux kernel modified on your name, then you can be enough called an ultra-craze.

In the best case you can have a whole chosen distribution of Linux running on your handy, supporting all devices (screen, keypad, GSM, wifi, bluetooth, IR, USB etc)

We rarely end up on the best case, but we are fighting not to stuck in the worst one, by trying to find a Linux-friendly mobile phone.

Wiki your mobile phone(s) hardware specs. You will most of the time find out that the CPU is an ARM family processor, which is “good” because you can download an ARM compiled Linux image to add those two numbers for you..

If the internal chips of you mobile phone are wired together based on an open composition of hardware parts, such as TI OMAP (on Nokia N70, or a successful Linux on Siemens SX1), your future may be brighter.

Linux (kernel) is started when its kernel image is loaded into the memory and is being executed by the CPU.
To prepare (clear, reset) the system for booting an operating system kernel, then finally to put its image into RAM you need another software (a boot loader) to do this, and it needs to have sufficient privileges to run.

You can (somehow) make this software run either from the cold boot (startup) finding a way to flash (overwrite) the internal ROM, which normally contains a boot loader for your (hated:)) Symbian, Sony Ericsson OS, Windows Mobile or other OS.
Here is the point when you enter the system programming world: you have to know the ways to flash ROM — manufacturers try to protect it by all means for people/businesses not to tamper with their phones, — basically it’s again all about finding security holes..

If flashing ROM cannot be achieved, you need to see what you can do from within the running phone’s native operating system (I let alone the JTAG and soldering iron solutions for ultra-geeks and do not describe them here)

If it is possible to develop software for your mobile phone in something lower-level than Java (Symbians SDK C++, C on Windows Mobile) and the executing code would have or would give your program (another security hole search..) the kernel-mode privileges, you can consider yourself lucky and start programming a boot loader, which would clean/resetCPU registers, display, memory and other ports away from the running OS, and then to load the kernel’s image bootloader (U-Boot, or other loaders) from a storage (SD card) into memory, and would make the processor to execute it, you can consider calling yourself a lucky Linux spawn-er.

This is not the end: U-Boot has to be compiled for your phone’s architecture, and internal hardware wiring, so it could continue resetting the system and loading the actual Linux kernel image into memory. U-Boot for OMAP exists (luckily), but still has undergone numerous patchworks by low-level system programmers, who were devoted to have Linux on the aforementioned Siemens SX1.

In any case if you are not an expert in this field, you need to build a network of support from the people in that area of low-level system programming, to help you out when you get stuck.

Good luck Linux freaks! :)


Linux File System

Linux uses a whole different file system philosophy than Windows. Windows automatically assigns a drive letter to every partition and drive it finds. But Linux makes every partition and drive a subdirectory of the root (/) partition. If you are a Windows user, you may get confused when you try to use Linux. No matter how many partitions, hard drives, or floppy drives your computer has, the Linux File Manager displays everything in a single directory tree under the root directory indicated by a slash (/). Every partition or drive is “mounted” onto the directory tree, and appears in File Manager as a subdirectory.

Linux needs at least three partitions to work, the root partition, the /boot partition, and the swap partition. The root partition is mounted at startup. The root directory itself doesn’t contain any files, just subdirectories. The /boot partition contains files used to boot the system. The swap partition is used as “virtual memory”.

When the operating system needs more memory than there is available in the system’s RAM, it can use disk space to emulate memory. As the system operates, data is swapped back and forth between RAM and the swap partition. The swap partition doesn’t have a mount point because it’s a system file and is never accessed directly by the user.

Note: Linux, the Internet, and the rest of the computing world use forward slashes to form directory paths. Only Windows uses back-slashes to form directory paths. The back-slash also represents an ASCII escape character, resulting in all kinds of bugs in Windows programs. In Windows you just insert a floppy disk into the drive and it’s accessible. With Linux, before you can access devices such as a CD ROM or a floppy drive, you have to “mount” the drive. For example, to mount the floppy drive, insert the disk into the drive and then select Main Menu | Programs | System | Disk Manager. The “User Mount Tool” utility will appear. In the “User Mount Tool” click on the “Mount” button to the right of /dev/fd0.

Note: Linux abstracts every device attached your computer, including the hard drive and floppy drive as a file. Files in the /dev/ folder are equivalent to device driver files in Windows. Linux provides device files for most common devices, but if you install an uncommon device, you may need a special device file.

After mounting the drive, you can access the floppy disk. Before removing the disk, you have to “unmount” the drive. If you find yourself frequently mounting and unmounting drives, you can right-click on “Disk Manager” in the menu and select “Add this launcher to panel”.

When you installed Linux, information about devices on computer was stored in the file /etc/fstab. If the device that you want to mount was not configured during installation, use the LinuxConf utility to configure the device before you mount it.

For example, if you wanted to configure a floppy drive to access DOS floppy disks, insert a DOS floppy disk into the drive, then log in as root and open LinuxConf – Main Menu | Programs | System | LinuxConf. In the LinuxConf window Config tab, click on “+” next to “File systems” to open that branch. Under “File systems” click on “Access local drive”. The “Local volume” windows appears.

In the “Local volume” window, click on the Add button. The “Volume specification” window appears. In the “Partition” text box type /dev/fd0. Then click on the drop down button for the “Type” text box and select msdos. In the “Mount point” text box type /mnt/floppy. Click on the “Accept” button. Then click on the “Mount” button.

Note: To mount a partition or drive you have to use an existing subdirectory as the mount point. By convention, drives use the /mnt/ subdirectory as the mount point. To copy files to and from the mounted floppy diskArticle Search, drag and drop them to and from the directory /mnt/dosfloppy just as you would any other directory.

Configure a Linux Ntp Server

NTP server systems fall into two categories: primary reference servers and secondary reference servers. Primary reference servers use an external timing reference to provide time, such as GPS or radio clocks. Secondary reference servers synchronise with primary reference NTP servers and offer slightly reduced accuracy. Primary reference servers are designated stratum 1 servers, while secondary servers have a stratum greater than 1.

The NTP Distribution

The NTP source code is freely available from the Network Time Protocol web site. The current version available for download is 4.2.4. NTP is available for the Linux operating systems with ports available for Windows NT. Once the source code is downloaded, it should be configured, compiled and installed on the host machine. Many Linux operating systems, such as RedHat, offer NTP RPM packages.

Configuring NTP

The ‘ntp.conf’ file is main source of configuration information for a NTP server installation. Amongst other things, it contains a list of reference clocks that the installation is to synchronise. A list of NTP server references is specified with the ‘server’ configuration command thus:

server time-a.nist.gov # NIST, Gaithersburg, Maryland NTP server

server time-c.timefreq.bldrdoc.gov # NIST, Boulder, Colorado NTP server

Controlling the NTP Server Daemon

Once configured, the NTP daemon can be started, stopped and restarted using the commands: ‘ntpd start’; ‘ntpd stop’ and ‘ntpd restart’. The NTP server daemon can be queried using the ‘ntpq -p’ command. The ntpq command queries the NTP server for synchronisation status and provides a list of servers with synchronisation information for each server.

NTP Access Control

Access to the NTP server can be restricted using the ‘restrict’ directive in the ntp.conf file. You can restrict all access to the NTP server with:

restrict default ignore

To only allow machines on your own network to synchronize with the server use:

restrict mask nomodify notrap

Multiple restrict directives can be specified in the ntp.conf file to restrict access to a specified range of computers.

Authentication Options

Authentication allows a matching passwords to be specified by the NTP server and associated clients. NTP keys are stored in the ntp.keys file in the following format: Key-number M Key (The M stands for MD5 encryption), e.g.:

1 M secret

5 M RaBBit

7 M TiMeLy


In the NTP configuration file ntp.conf, specify which of the keys specified above are trusted, i.e. are secure and you want to use. Any keys specified in the keys file but not trusted will not be used for authentication, e.g.:

trustedkey 1 7 10

The NTP server is now configured for authentication.

Client Configuration for Authentication

The client needs to be configured with similar information as the server, however, you may use a subset of the keys specified on the server. A different subset of keys can be used on different clients, e.g.:

Client A)

1 M secret

7 M TiMeLy

trustedkey 1 7

Client B)

1 M secret

5 M RaBBit

7 M TiMeLy


trustedkey 7 10

Essentially authentication is used by the client to authenticate that the time server is who he says he is, and that no rogue server intervenes. The key is encrypted and sent to the client by the server where it is unencrypted and checked against the client keys to ensure a match.

RAID on Linux

For Raid

MTBF of Array = MTBF of individual drive/ Total no of drive in array

Therefore in Raid Mean time between failures (MTBF) is less as compared to SLED.Raid helps in achieving redundancy, low latency, higher bandwidth for reading and writing. It also helps recovery at the time of hard-disk crash.

Raid offers different level. They are as fallows:

1. Raid – 0
It has more improved performance and data storage capacity but is not redundant.
Therefore failure of any disk results in data lost. It is also called “striping”.

2. Raid – 1
It provides redundancy by writing all data in two disks. The speed of accessing data becomes faster. But the array capacity is equal to the capacity of one member disk. Therefore it is more expensive. This also referred as “Mirroring”.

3. Raid -2
It uses Hamming error correction code correction.

4. Raid -3
It strips data at byte level across several drives with parity stored on one drive.

5. Raid -4
It stripes data at block level from several drives with parity stored on one drive.
The speed of reading data is fast enough but for writing it is slow. Since writing requires the parity data be updated each time.

6. Raid-5
It distributes the parity among all drives. If the drive fails need replacement but the array is not destroyed by the single disk failure.

7. Raid-6
It is stripped with dual parity. If two drives fail the array continues the operation.
It provides more safety of data.

There are two types of raid solution in Linux:

1. Software Raid Solution:
It offers cheaper raid solution not only for expensive disk controller cards but also works with cheaper IDE disks as well as SCSI disks. There are two Linux software RAID implementation: MD (multi-disk) driver and the EVMS driver.

2. Hardware Raid Solution
The hardware-based system manages the RAID subsystem independently from the host and presents to the host only a single disk per RAID array.

If anyhow you lost your Linux file you are not able to recover it. You become very much frustrated you don’t know what to do .You can use Linux recovery software. It helps you to recover your ext2, ext3 and Resier Linux file without any extra efforts. Stellar Phoenix Linux data recovery provides you the complete solution for your lost data.

Linux Console – Virtual Terminal & Terminal Windows

There are several Linux terms that are the same or similar. And this “Linux Concepts & Terms Summary” article describes several terms that are the same – and others that are related.

Linux Terms: Linux Console, Linux Terminal and Linux Terminal Emulation Windows

First, You Need to Know About Linux Systems – With and Without Linux Desktops

You can install a Linux system with a desktop and this gives you a point-and-click working environment with icons and menus, like a Windows desktop – but much better!

Or you can install a Linux system without a desktop.

Linux tips: Linux servers are very often installed without a Linux desktop because a desktop is not required on some servers.

Linux Console and Linux Terminal

When you boot a Linux system without a desktop you see a black screen with a Login: prompt. This is commonly referred to as a Linux console.

At this point, you can log in as a Linux user and the Linux command line prompt appears. At this prompt, you can run Linux commands and Linux software programs.

A Linux console is also referred to as a Linux terminal.

Linux Terminal (Emulation) Windows

When you boot a Linux system that has a desktop installed, you boot to a GUI login prompt and log in to the Linux desktop.

At the Linux desktop, you can do some steps to open a terminal window on the desktop. A Linux terminal window is also know as a terminal “emulation” window. This window “emulates” a Linux terminal (a.k.a. console).

When you open a terminal emulation window, the Linux command line prompt appears and you can run Linux commands and Linux software programs.

Linux Tips: You can open multiple terminal emulation windows and hold down the Alt key and press the Tab key to move from one window to another.

Linux Virtual Terminal

From the Linux desktop, you can go to a Linux virtual terminal (a.k.a “vt”), that “emulates” the Linux terminal (a.k.a. console) that appears when you boot a Linux system that doesn’t have a desktop.

There are often six virtual terminals available and you press Ctrl+Alt+Fx to go to a virtual terminal. Replace the x in Fx with the number of a function key on your keyboard.

For example, to go from the Linux desktop to virtual terminal 1, hold down Ctrl and Alt and press F1 (and hope you don’t get a cramp). To go to vt 2, just press F2 instead of F1.

Linux Tips: You can’t access the virtual terminals from within some Linux virtual machines.

Imagine watching a Linux video tutorial that shows you all the steps described above, so you can easily learn how to work with all the different types of Linux terminals. Then pausing the video so you can try these steps yourself!

Embedded Linux in simple

Simple Embedded Linux System
by Vincent Sanders and Daniel Silverstone


Constructing an embedded system with Linux is often seen as a complex undertaking. This article is the first in a series which will show the fundamental aspects of constructing such systems and enable the reader to apply this knowledge to their specific situation.

This first article covers the construction of the most basic system possible, which will provide a command shell on the console. Along with the rest of the series, it assumes a basic understanding of a Linux-based operating system. While discussing concepts and general approaches, these concepts are demonstrated with extensive practical examples. All the practical examples are based upon a Debian- or Ubuntu-based distribution.

What is an embedded system?

The term “Embedded System” has been applied to such a large number of systems that its meaning has become somewhat ill-defined. The term has been applied to everything from 4-bit microcontroller systems to huge industrial control systems.

The context in which we are using the term here is to refer to systems where the user is limited to a specific range of interaction with a limited number of applications (typically one). Thus, from the whole spectrum of applications which a general purpose computer can run, a very narrow selection is made by the creator of the embedded system software.

It should be realized that the limits of interaction with a system may involve hardware as well as software. For example, if a system is limited to a keypad with only the digits 0 to 9, user interaction will be more constrained than if the user had access to a full 102-key keyboard.

In addition to the limiting of user interaction, there may also be limits on the system resources available. Such limits are typically imposed by a system’s cost, size, or environment. However, wherever possible, these limits should be arrived at with as much knowledge of the system requirements as possible. Many projects fail unnecessarily because an arbitrary limit has been set which makes a workable solution unachievable. An example of this would be the selection of a system’s main memory size before the application’s memory requirements have been determined.

What do you want to achieve?

A project must have a clearly defined goal.

This may be viewed as a statement of the obvious, but it bears repeating as for some unfortunately inexplicable reason, embedded systems seem to suffer from poorly-defined goals.

An “embedded” project, like any other, should have a clear statement of what must be achieved to be declared a success. The project brief must contain all the requirements, as well as a list of “desirable properties.” It is essential that the two should not be confused; e.g., if the product must fit inside a 100mm by 80mm enclosure, that is a requirement. However, a statement that the lowest cost should be achieved is a desirable item, whereas a fixed upper cost would be a requirement.

If information necessary to formulate a requirement is not known, then it should be kept as a “desirable item” couched in terms of that unknown information. It may be possible that once that information is determined, a requirement can be added.

It is, again, self-evident that any project plan must be flexible enough to cope with changes to requirements, but it must be appreciated that such changes may have a huge impact on the whole project and, indeed, may invalidate central decisions which have already been made.

General IT project management is outside the scope of this article. Fortunately there exist many good references on this topic.

Requirements which might be added to a project brief based on the assumptions of this article are:

  • The system software will be based upon a Linux kernel.
  • The system software will use standard Unix-like tools and layout.

The implications of these statements mean the chosen hardware should have a Linux kernel port available, and must have sufficient resources to run the chosen programs.

Another important consideration is what kind of OS the project warrants. For example, if you have a project requirement of in-field updates, then you may want to use a full OS with package management, such as Debian GNU/Linux or Fedora. Such a requirement would, however, imply a need for a non-flash-based storage medium such as a hard disc for storing the OS, as these kinds of systems are typically very large (even in minimal installations), and not designed with the constraints of flash-based storage in mind. However, given that additional wrinkle, using an extant operating system can reduce software development costs significantly.

Anatomy of a Linux-based system

Much has been written on how Linux-based systems are put together; however a brief review is in order, to ensure that basic concepts are understood.

To be strictly correct the term “Linux” refers only to the kernel. Various arguments have been made as to whether the kernel constitutes an operating system (OS) in its entirety, or whether the term should refer to the whole assemblage of software that makes up the system. We use the latter interpretation here.

The general steps when any modern computer is turned on or reset is:

  • The CPU (or designated boot CPU on multi-core/processor systems) initializes its internal hardware state, loads microcode etc.
  • The CPU commences execution of the initial boot code, e.g., the BIOS on x86 or the boot-loader on ARM.
  • The boot code loads and executes the kernel. However, it is worth noting that x86 systems generally use the BIOS to load an intermediate loader such as GRUB or syslinux, which then fetches and starts the kernel.
  • The kernel configures the hardware and executes the init process.
  • The init process executes other processes to get all the required software running.

The kernel’s role in the system is to provide a generic interface to programs, and arbitrate access to resources. Each program running on the system is called a process. Each operates as if it were the only process running. The kernel completely insulates a program from the implementation details of physical memory layout, peripheral access, networking, etc.

The first process executed is special in that it is not expected to exit, and is expected to perform some basic housekeeping tasks to keep a system running. Except in very specific circumstances, this process is provided by a program named /sbin/init. The init process typically starts a shell script at boot to execute additional programs.

Some projects have chosen to run their primary application as the init process. While this is possible, it is not recommended, as such a program is exceptionally difficult to debug and control. A programming bug in the application halts the system, and there is no way to debug the issue.

One feature of almost all Unix-like systems is the shell, an interactive command parser. Most common shells have the Bourne shell syntax.

A simple beginning

We shall now consider creating a minimal system. The approach taken here requires no additional hardware beyond the host PC, and the absolute minimum of additional software.

As already mentioned, these examples assume a Debian or Ubuntu host system. To use the QEMU emulator for testing, the host system must be supported by QEMU as a target. An example where this might not be the case is where the target system is x86-64, which QEMU does not support.

To ease construction of the examples, we will use the kernel’s initramfs support. An initramfs is a gzip-compressed cpio archive of a file system. It is unpacked into a RAM disk at kernel initialization. A slight difference to normal system start-up is that while the first process executed must still be called init, it must be in the root of the file system. We will use the /init script to create some symbolic links and device nodes before executing the more-typical /sbin/init program.

This example system will use a program called Busybox, which provides a large number of utilities in a single executable, including a shell and an init process. Busybox is used extensively to build embedded systems of many types.

The busybox-static package is required to obtain pre-built copy of the Busybox binary and the qemu package is required to test the constructed images. These may be obtained by executing:

$ sudo apt-get install busybox-static qemu


As mentioned, our initramfs-based approach requires a small /init script. This configures some basic device nodes and directories, mounts the special /sys and /proc file systems, and starts the processing of hotplug events using mdev.


# Create all the busybox symbolic links
/bin/busybox --install -s

# Create base directories
[ -d /dev ] || mkdir -m 0755 /dev
[ -d /root ] || mkdir --mode=0700 /root
[ -d /sys ] || mkdir /sys
[ -d /proc ] || mkdir /proc
[ -d /tmp ] || mkdir /tmp
mkdir -p /var/lock

# Mount essential filesystems
mount -t sysfs none /sys -onodev,noexec,nosuid
mount -t proc none /proc -onodev,noexec,nosuid

# Create essential filesystem nodes
mknod /dev/zero c 1 5
mknod /dev/null c 1 3

mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2

mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1

echo "/sbin/mdev" > /proc/sys/kernel/hotplug

echo "Creating devices"
/sbin/mdev -s

exec /sbin/init


To construct the cpio archive, the following commands should be executed in a shell. Note, however, that INITSCRIPT should be replaced with the location of the above script.

$ mkdir simple
$ cd simple
$ mkdir -p bin sbin usr/bin usr/sbin
$ cp /bin/busybox bin/busybox
$ ln -s busybox bin/sh
$ cp INITSCRIPT init
$ chmod a+x init
$ find . | cpio --quiet -o -H newc | gzip >../simple.gz
$ cd ..


To test the constructed image use a command like:

$ qemu -kernel /boot/vmlinuz-2.6.26-1-686 -initrd simple.gz \
             -append "root=/dev/ram" /dev/zero


This should present a QEMU window where the OS you just constructed boots and displays the message “Please press Enter to activate this console.” Press enter and you should be presented with an interactive shell from which you can experiment with the commands Busybox provides. This environment is executing entirely from a RAM disc and is completely volatile. As such, any changes you make will not persist when the emulator is stopped.

Booting a real system

Starting the image under emulation proves the image ought to work on a real system, but there is no substitute for testing on real hardware. The syslinux package allows us to construct bootable systems for standard PCs on DOS-formatted storage.

A suitable medium should be chosen to boot from, e.g., a DOS-formatted floppy disk or a DOS-formatted USB stick. The DOS partition of the USB stick must be marked bootable. Some USB sticks might need repartitioning and reformatting with the Linux tools in order to work correctly.

The syslinux program should be run on the device /dev/fd0 for a floppy disk, or something similar to /dev/sdx1 for a USB stick. Care must be taken, as selecting the wrong device name might overwrite your host system’s hard drive.

The target device should then be mounted and the kernel and the simple.gz file copied on.

The syslinux loader can be configured using a file called syslinux.cfg which would look something like:

default simple
timeout 100
prompt 1

label simple
  kernel vmlinuz
  append initrd=simple root=/dev/ram


The complete command sequence to perform these actions, substituting file locations as appropriate, is:

$ sudo syslinux -s /dev/sdd1
$ sudo mount -t vfat -o shortname=mixed  /dev/sdd1 /mnt/
$ cd /mnt
$ sudo cp /boot/vmlinuz-2.6.26-1-686 VMLINUZ
$ sudo cp simple.gz SIMPLE
$ sudo cp syslinux.cfg SYSLINUX.CFG
$ cd /mnt
$ sudo umount /mnt


The device may now be removed and booted on an appropriate PC. The PC should boot the image and present a prompt exactly the same way the emulator did.

What’s next?

This first step, while simple, provides a complete OS, and demonstrates that constructing an embedded system can be a straightforward process.

The next step is to expand this simple example to encompass a specific application, which will be covered in the next article.

How Boot Loaders Work

What BIOS does for us

The BIOS is the firmware in the ROM of a PC. When the PC is powered up, the BIOS is the first program that runs. All other programs must be loaded into RAM first. The BIOS contains the following parts:

  • POST (Power On Self Test). The running counter that counts the kilobytes of main memory is the most visible part of the POST.
  • The Setup Menu, that lets you set some parameters and lets you adjust the real time clock. Most modern BIOS versions let you set the boot order, the devices that BIOS checks for booting. These can be A (the first floppy disk), C (the first hard disk), CD-ROM and possibly other disks as well. The first device in the list will be tried first. Older BIOS-es have only one boot order: A, C. So the BIOS will try to boot from A first and if there is no diskette in the drive it tries to boot from C.
  • The boot sector loader. This loads the first 512-byte sector from the boot disk into RAM and jumps to it. This is where the boot loaders described in this paper start.
  • The BIOS interrupts. These are simple device drivers that programs can use to access the screen, the keyboard and disks. Boot loaders rely on them, most operating systems do not (the Linux kernel does not use BIOS interrupts once it has been started). MSDOS does use BIOS interrupts.

Apart from the main BIOS there are extension ROMs, which are started by the main BIOS. Every VGA card has one. Also SCSI host adapters and Ethernet cards can have an extension ROM. It is even possible to put an EPROM on an Ethernet card to boot a machine over the network without any disks.

As far as boot loading facilities are concerned, the PC BIOS is very primitive compared to that of other computer systems. The only thing it knows about disks is how to load the first 512-byte sector.

  • The first sector of a diskette can be loaded at address 0000:7C00. The last two bytes of the sector are checked for the values 0x55 and 0xAA, this as a rough sanity check. If these are OK, the BIOS jumps to the address 0000:7C00.
  • Booting from a hard disk is very similar to booting from a diskette. The first sector of a hard disk (often called the Master Boot Record) is loaded at 0000:7C00 and next the BIOS jumps to it. The MBR program must move itself to an address that is different from 0000:7C00 as it is supposed to load a different boot sector from a partition to address 0000:7C00 and jump to that.
  • Modern BIOS versions can treat a certain file on a CD-ROM as a diskette image. They pretend to boot from a diskette by loading the first 512 bytes of the file to 0000:7C00 and jumping to it. Every attempt to access the same diskette using the BIOS routines, will be redirected to the image file on CD-ROM. Some other ways to boot a CD-ROM may also be supported (with an emulated hard disk or with no disk emulation at all).

When the boot sector is loaded, the CPU is in real mode. For those who are unfamiliar with 80×86 architecture: real mode is very limited compared to 32-bit protected mode (in which Linux runs). For example: data outside a 64K segment can only be accessed if you change a segment register and data outside the first 1MB of address space (which contains 640kB of main memory) cannot be accessed at all. As gcc does not know about real mode, programs compiled with it can only be run in real mode with some tricks and with severe memory size restrictions. This is the reason why most boot loaders (except GRUB) are written in assembly. All boot sector programs, even that of GRUB, are written in assembly1.

In theory a boot loader could do its job by directly accessing the bare metal, but 512 bytes would be a very small space for that. The boot loader has access to BIOS interrupts, which are subroutines that can be invoked by the INT instruction (software interrupts). These work in real mode only. The following routines are used by most boot loaders.

  • INT 0x10 for screen output.
  • INT 0x16 for keyboard input.
  • INT 0x13 for disk I/O. The parameters to specify sectors on disk used to have a very limited range. Originally it was only possible to specify 1024 cylinders on a hard disk, while hard disks can have more cylinders. This imposed limitations on where it was allowed to put the boot loader and any files accessed by it. You were forced to create a small partition near the start of the hard disk and put the boot loader there. There are three categories of BIOS:
    • BIOS versions earlier than 1995 could only access IDE disks of around 500MB, as the BIOS sector and head numbers corresponded directly to the register values on the IDE interface.
    • BIOS versions between 1995 and 1998 can access IDE disks up to about 8GB. They translate the cylinder, head and sector numbers from the INT 0x13 call to different values that better utilize the allowable ranges on the IDE interface.
    • BIOS versions of 1998 or later have a new calling interface using linear block addresses.

    In any of the three categories you have BIOS-es that have bugs that cause them to stop at a lower disk size limit (a category 2 BIOS that should work up to 8GB, but stops at 2GB). In those cases it makes sense to upgrade to a new BIOS version.

  • INT 0x15 is a catch-all for many BIOS functions, one of which is moving data to extended memory (the BIOS is required to switch to protected mode temporarily to do that). Other functions are for disabling the A20 gate and for determining the memory size.


Parts of a boot loader

A boot loader typically consists of three programs:

  • The boot sector program is directly loaded by the BIOS at boot time and is only 512 bytes in size.
  • The second stage program is loaded by the boot sector program and it does everything you expect the boot loader to do.
  • The boot loader installer is not run when the system is booted, but it is used to install the boot loader and the second stage program onto the boot disk. These have to be stored in special locations, so they cannot be copied with cp.


boot sector program

The boot sector program can only be 512 bytes in size and not all 512 bytes are even available in all cases. The last two bytes must be 0x55 and 0xAA for the BIOS. The Master Boot Record on a hard disk contains the partition table of 64 bytes, so only the first 446 bytes can be used. If the boot sector program must exist on a DOS partition or on a DOS diskette, there must be a parameter block at the start of the boot sector.

Because of these size restrictions, boot sector programs are just about the only remaining examples of programs on the PC platform that are truly optimized for size and have to be written in assembly for this reason. Further, a boot sector program cannot do everything you want a boot loader to do. Usually a boot sector program does one of the following things (not all three in one program):

  • Load another boot sector. This is typical for a boot sector program that lives in the master boot record of a hard disk. It can find the first sector of the selected active partition and chain load that. The MBR program that came traditionally with MS-DOS has no ability to change the active partition at boot time. There are other boot sector programs that let you select a partition by pressing a key, such as the MBR program of LILO.
  • Load a second stage boot loader. It is generally not possible for a boot sector program to look into the directory for a file with a specific name and load that into memory, but exceptions exist, at least for DOS file systems2. Most boot sector programs find the second stage by sector number rather than by name. The sector numbers have to be put into the boot sector by the boot loader installer.
  • Load the kernel directly. A kernel is typically much larger than a second stage boot loader.The boot sector program in the Linux kernel loads the kernel directly into memory without the need for a second stage boot loader. As the kernel is located in contiguous sectors on a diskette, there is no need to traverse file system data structures. However, for bZimage kernels the boot sector program cheats; it invokes a subroutine in the setup part of the kernel for loading the rest of the kernel into high memory.

    The boot loader e2boot fits into the first 1kB block of an ext2 partition (it is twice as big as a boot sector program), but with some tricks it finds both the kernel and the RAM disk by name on an ext2 partition and loads them into memory.

    Also the boot sector on a DOS disk does not utilize a second stage boot loader to load the MS-DOS kernel files IO.SYS and MSDOS.SYS. The structure of an MSDOS file system is simple enough to find a file with a specific name in the root directory and load it into memory, at least part of it..


second stage of boot loader

This is the real boot program. It contains the user interface and the kernel loader. It can be anywhere from 6.5 kilobytes (LILO) to over 100 kilobytes (GRUB) in size. It contains the following functions:

  • User interface. It is either a simple command line (old versions of LILO), a menu or both. It allows you to select any number of operating systems and to specify additional parameters to the operating system. The available options are specified by a configuration file. Modern versions of boot loaders can show their menu in a bitmap picture.
  • Operating system loader. loads the operating system into memory and runs it. Alternatively we can load another boot loader specific to another operating system and let it run. This is called chain loading.

LOADLIN is not a complete boot loader, but it has only the second stage (without the user interface). It is run from DOS, and it can make use of DOS system calls to read files from disk. What makes its task harder than that of a normal boot loader, it that it must be able to work its way out of some types of memory managers.


Boot loader installer

The third part of the boot loader is only run when the boot loader is installed on a disk. As opposed to the boot sector program and second stage, this is a normal Linux program. In the case of LILO the installer must be rerun each time the configuration is changed or any file has been updated. It performs the following tasks:

  • Install the boot sector. If the boot sector will be installed in the MBR of a hard disk or on a DOS file system, not all 512 bytes may be overwritten, but the partition table or the DOS parameter block must be preserved.
  • Tell the boot sector where the second stage boot loader is. Usually it writes one or more sector addresses into the boot loader.
  • Tell the second stage boot loader where all relevant information is (configuration, kernels). This is the case with LILO. LILO creates a map file that contains all relevant sector addresses and puts pointers to the map file in the boot sector and/or second stage boot loader.


Loading the operating system


Loading the Linux kernel

A Linux kernel consists of the following parts:

  • The boot sector (see arch/i386/boot/bootsect.S). This is only run if Linux is booted directly from a diskette.
  • The setup part with real mode initialization code (transition to protected mode) (see arch/i386/boot/setup.S)
  • The rest of the kernel, which in turn consists of the following parts:
    • Protected mode initialization code
      (see arch/i386/boot/compressed/head.S).
    • A decompression program (compiled C code, see
      arch/i386/boot/compressed/misc.c and lib/inflate.c).
    • The real kernel, which is compressed. After decompression this kernel consists of the following parts:
      • Protected mode initialization code (see arch/i386/boot/head.S).
      • Main C routine (see init/main.c).
      • All the rest. Relevant for this discussion is the RAM disk driver (see drivers/block/rd.c). This will be further explained in section 4

A Linux boot loader should support the following tasks:

  • Loading the Linux kernel into memory.
    • The boot sector (which will not be run) and the setup part of the kernel are loaded near the top of low memory (usually address 9000:0000).
    • If it is not a bzImage type kernel, the rest of the kernel will be loaded in low memory at 0000:1000).
    • If it is a bzImage type kernel, the rest of the kernel will be loaded in high memory, starting at 0x100000.

    The boot loader does not know or care that the rest of the kernel contains a compressed part.

  • Passing a command line to the kernel. This command line can come from a configuration file or it can be entered interactively by the user.
  • Loading an initial RAM disk into memory and passing it to the kernel. The initial RAM disk will be loaded near the top of high memory above the kernel.
  • Starting the kernel. The boot loader must set some relevant parameters in the setup part and jump to it. From there the kernel takes control and the boot loader’s part is over. Next the kernel starts as follows:
    • The setup code saves relevant parameters and the command line for later.
    • The setup code checks how much memory is available, performs some hardware initialization and prepares to enter protected mode.
    • In protected code, the rest of the kernel is being decompressed3.
    • After decompression the head.S and the main C routine will initialize all parts of the kernel. This will show a lot of messages.
    • Finally the init process will be started (or first its linuxrc variant on an initial RAM disk).


Chain loading

Most boot loaders are designed to boot only one operating system. LILO knows only to load Linux kernels and the DOS boot sector can load only DOS. If you want to select between several different operating systems, it is not likely that you find a boot loader that can load all of them. But at least every operating system is supposed to be booted by a 512-byte boot sector that can be loaded by the BIOS and there lies the key. Any sufficiently advanced boot loader supports chain loading.

If a boot loader loads a boot sector of another operating system, it is called chain loading. This boot sector can directly be loaded from the disk or partition or it can be loaded from a file. For the other operating system it should not make a difference whether its boot sector was loaded by the BIOS or by another boot loader. In reality a boot sector of a partition is normally loaded by a master boot record program. Also in this case, it should make no difference if this is loaded by a more advanced boot loader (such as LILO) instead.

The following chain loading scenarios are possible.

  • Linux boot loaders can chain load almost any other operating system.
  • Linux boot loaders can be chain loaded by boot managers of other operating systems. It is possible to boot Linux from the Windows NT boot manager or the OS/2 boot manager.
  • Linux boot loaders can chain load Linux boot loaders as well. This may make sense on computers with several independent Linux systems installed, where each Linux installation has its own local LILO and these can be selected by a central instance of LILO to chain load them. Instances of LILO can even exchange command lines between them.


Configuring the boot loader

Both LILO and GRUB have a configuration file that specifies several menu options, each representing either a Linux kernel or a different operating system to boot. For each Linux kernel a command line and an initial RAM disk can be specified. Apart from syntactic details the contents of these configuration files look remarkably similar. But there is an essential difference:

  • LILO reads its configuration file at installation time. Every time the configuration file, the kernel or any initial RAM disk is changed, the LILO installer must be rerun. At boot time the configuration file is not read. The second stage boot program of LILO does not know how to find files in the file system. It relies on a map file to find data blocks of the necessary files. This map file was created by the LILO installer.
  • GRUB and also SYSLINUX read their configuration files at boot time. You can install the boot loader once and just change configuration files, kernels and RAM disk images without trouble. The second stage boot program knows how to find files in the file system.