Open Library is an open library of educational information. Operating System Boot Steps Command Overview

A bootloader is a system program that performs bootstrapping. Many bootloaders also provide moving and linking. Some systems separate the linking function from the move and load functions. Linking is done by a special linking program (or link editor), moving and loading is done by a loader.

Linking is the linking of two or more separate, translated programs.

Relocation is a modification of an object program so that it can be loaded from a different address than the original.

Bootloader functions:

distribution of OP;
moving the program;
linking modules;

EP distribution

Moving the program

If there are address constants inside the modules, which are calculated from the beginning of the module, then the addresses will be corrected relative to the Base.

Linking modules

Types of loaders

Compile-Run Loaders

One of the possible ways to perform the loader function can be such an organization of the assembler's work, in which the assembler, working in one part of memory, places machine instructions and data as it is assembled directly into the memory cells allocated for them. After compilation is complete, the assembler transfers control to the entry point of the resulting program. This is a very simple solution that eliminates the need for any additional procedures. This is called compile-execute, and the loader consists of a single instruction that transfers control to the assembled program.

Absolute loaders are easy to implement, but have a number of features:

the task of distributing the OP is performed by the programmer (using the directive of setting the initial value of the OP);
the task of moving the program is performed by the compiler;
linking modules - decided by the programmer (call 600);
loading programs into the OP and launching them for execution.

Advantages:

smaller bootloader size (in terms of memory size);
separation of the compilation and loading phases, which reduces the time for processing modules;
the ability to use several programming languages, because the structures of the created object modules are identical.

Disadvantages:

A large amount of work falls on the programmer. It is necessary to constantly monitor changes in starting addresses when modifying modules, because their length changes.

Absolute Loader Object File Structure

The information record consists of:

sign;
the absolute address of the OP where information can be transferred;
the number of information bytes in the message;
bytes of information;
checksums;
numbering.

The control record consists of:

sign;
entry point address.

Simple absolute loader operation:

Check if there is enough memory for this program (viewing the first record).
Sequential reading of the program body and placement at the specified address.
Transfer of control to the address for program execution.

Custom bootloader

To avoid the need to reassemble all subroutines when a change is made to one of them, and also to free the programmer from the tasks of memory allocation and communication of subroutines, so-called loaders were developed. This loader allows multiple program segments and one data segment (common segment) to be present in the program. The assembler translates each segment separately and provides the loader with text and information regarding movements and cross-references between segments.

The output of the assembler with this scheme is an object program and information about all other programs to which there are calls in this program. In addition, there is information about those places that should be changed during loading (information about movement), i.e. about cells, the contents of which depend on the location of the program in memory.

For each source program, the assembler generates text (translation result) as output information, preceded by a branch vector containing the addresses of the names of the subroutines that are accessed in the source program. For example, if the SQRT subroutine is the first subroutine to be called, then the first cell in the branch vector will contain the symbolic name SQRT. Sentences containing a call to the SQRT subroutine will be translated into a branch instruction indicating the address of the branch vector element associated with the SQRT. The assembler will also pass additional information such as the total length of the program and the length of the branch vector. After loading the program text and the branch vector into memory, the loader will load each subroutine specified in the vector. Then he will put a command to go to the corresponding subroutine in each element of the vector. Thus, a call to the SQRT subroutine will result in the execution of the jump command to the first cell of the jump vector, which will contain the jump command to the called subroutine.

Such a loading scheme with two-stage control transfer is often used in computers with a fixed command format and direct addressing.

This loader has several disadvantages:

the transition vector is not quite convenient for loading and saving external data (located in another program segment);
the branch vector increases the length of the object program;
the loader works with program segments, but does not facilitate access to data segments that can be shared by multiple routines.

Directly linking bootloader

The direct linking loader provides the most complete ability to move programs and data in memory and is currently the most common. Such a loader has the advantage that it allows the use of a large number of both program segments and data segments and gives the programmer complete freedom to access data located in other segments, while allowing for separate translation.

The assembler (translator) must pass the following information to the loader with each program and data segment:

segment length;
a list of all segment symbols that can be accessed from other segments, and their relative addresses;
a list of all characters that are not defined in this segment, which are accessed in this segment;
information about the location of address constants in the segment and a description of how their values should be changed;
machine codes obtained as a result of translation, and assigned relative addresses.

One of the drawbacks of a direct linking loader in its simplest form is the need to re-execute the functions of memory allocation, movement, linking, and loading of all necessary subroutines each time the program is executed. These problems can be resolved by performing loading with two separate programs: a combiner and a module loader. The output of the combiner is a set of data in a format that allows the program to be loaded into memory, and is called a load module. There are several types of combiners. One is the so-called linker, which stores the information needed to move a module in memory so that the module as a whole can then be configured and loaded into an arbitrary location in memory. In this case, the module loader must perform the functions of memory allocation and movement, but remains free from solving the complex problem of linking object modules and subroutines.

Dynamic loader

In each of the considered schemes, it was assumed that all the necessary subroutines are loaded into memory at the same time. If the total amount of memory required for the routines is less than the available memory of the machine, it becomes difficult. These difficulties are overcome by using a dynamic loading scheme with a sequential combiner and loader. This scheme is based on the fact that usually different subroutines are required at different times and can be mutually exclusive. By explicitly defining which subroutine contains calls to other subroutines, you can define a so-called overlap structure (overlay structure) that specifies mutually exclusive subroutines.

A loading module is being formed. It is relocatable, it must contain a relocation table. Also, the structure of the load module must contain information about the links. The loader must contain such a part as the overlay manager, it selects from the load modules exactly those that are the starting ones, in the process of work organizes the loading of the necessary modules into the OP.

Dynamic linking

There are cases when, for the efficiency of using the memory of the machine, dynamic linking of subroutines is carried out already during the execution of the program. That is, subroutines are loaded into memory only as they are called. This can be beneficial because under certain conditions in the program, some subroutines may not be needed at all. Let's consider an example:

if (condition 1)
subroutine call 1
if (condition 2)
subroutine call 2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
if (condition m)
subroutine call m

Many of the branches will be skipped, and you will not have to load into the OP, for example, subroutine 2 if condition 2 is not met. In this case, the loader must work simultaneously with the program and perform the functions of linking and loading subroutines.

The operating system is stored in external memory, usually on a hard disk, less often on a floppy disk. For normal operation of the computer, it is necessary that the main modules of the operating system are in RAM. Therefore, after turning on the computer, an automatic rewriting (loading) of the operating system from the disk into the RAM is organized. The most important aspects of this download are shown in the flow chart in Fig. 9.13.

Rice. 9.13. Algorithm for loading the operating system from disk into RAM

After turning on the computer, you observe the change of numbers on the screen. These numbers represent the process of testing the RAM in the BIOS program. If a malfunction is detected in the cells of the RAM, a message will be displayed.

After successful completion of the hardware test, the floppy disk drive A is accessed, and the indication lamp next to it lights up. If you boot the operating system from a floppy disk, you must insert the system disk into drive A before or during testing. Otherwise, if there is no operating system on disk A, the hard disk is accessed, as evidenced by the indicator light next to it.

The reading into the RAM of the 0th sector of the 0th side of the disk, in which the bootloader is located (BOOT RECORD), begins. Control is transferred to the loader, which checks for the presence of the IO.SYS expansion module and the MSDOS.SYS base module on the system disk. If they are in their designated place (cm. rice. 9.10), then it loads them into RAM, otherwise a message about their absence will be displayed. In this case, it is recommended to reboot. The reboot signal transfers control to the persistent BIOS module, which rewrites the boot block from disk to RAM, and so on.

Remember! For rebooting the operating system in memory, press the keys at the same time .

After successfully loading the IO.SYS expander and the MSDOS.SYS base module into the RAM, the COMMAND.COM command processor is loaded and the CONFIG.SYS configuration file is processed, which contains the commands for connecting the necessary drivers. This file may not be present if you are satisfied with the base version of the operating system.

Then the batch file AUTOEXEC.BAT is processed. With the help of this file you can configure the parameters of the operating environment. For example, create a virtual disk, provide a change of print modes, load auxiliary programs, etc.

Attention! Files with the .BAT extension play a special role when working in the system environment. They contain a collection of operating system commands or executable file names. After starting the file with the .BAT extension, all the commands recorded in it are executed automatically one after the other.

The file with the standard name AUTOEXEC.BAT differs from other files of the .BAT type in that the execution of the commands placed in it starts automatically immediately after the operating system is loaded.

If the AUTOEXEC.BAT file is missing, you will be prompted to enter the date and time:

if you press the enter key, then the so-called system parameters, which are determined by the computer timer, will be taken as the current date and time;

if you want to reset the system date and time, then in response to the prompt, enter values in one of the provided forms, for example:

10-25-1997 (month day year)

7:30: 10.00 RUB (hours: minutes: seconds)

After the AUTOEXEC.BAT file finishes, and also if this file is not found, the system disk prompt will be displayed on the display screen, for example C: \>. This indicates that the boot process has completed normally, and you can get to work by entering the name of the application program or operating system command.

Note. The CONFIG.SYS and AUTOEXEC.BAT files may be missing. In this case, the operating environment settings will be set by default.

Remember! The hard disk must provide persistent storage of the operating system.

All floppy drives must be open when you turn on the computer.

Insert the floppy disk with application programs into the floppy drive after the download is complete.

TECHNOLOGY OF WORK IN MS DOS

§ Understanding Commands

§ Basic commands for working with directories

§ Basic commands for working with files

§ Basic commands for working with disks

§ Creating and using a batch file

§ Operating system autotuning command file AUTOEXEC.BAT

§ Configuring the operating system using the CONFIG.SYS configuration file

GENERAL INFORMATION ABOUT TEAMS

Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Volga University named after V. N. Tatishchev

Faculty of Informatics and Telecommunications

Department of Informatics and Control Systems

COURSE WORK

by discipline: "System software"

Theme: " Loader”

Is done by a student. IS-303

Krasnoseltsev V. NS.

Teacher: Trubacheva S.I.

Tolyatti

Introduction

1. Theoretical part

2. Design part

2.1 Statement of the problem

2.2 Development of an algorithm for solving the problem

2.3 Description of the algorithm for loading the application program

2.4 Description of the OS boot algorithm

2.5 Description of the Unix Boot Algorithm Using the LILO Boot Loader

Conclusion

References

Introduction

The relevance of my coursework lies in the fact that the development of computers and their operating systems went parallel to the development of various bootloader programs. Certain operating systems require different boot loaders to boot. For example, a multiuser Unix operating system requires the LILO loader and various utilities. Any loading of the operating system affects the RAM, with which both the primary loader and the secondary loader work. When loading, various types of errors occur, which the loader bypasses or completes the loading process (displays an informational message).

A bootloader is a program that more than one computer and more than one operating system simply cannot do without.

1 . Theoretical part

Microsoft OS boot process

Whichever operating system we are considering, in order for the OS to start controlling the computer, it must be loaded into RAM. Therefore, we will consider how the process of loading different OSes occurs. Since we are only interested in booting from hard drives, we will not consider the specifics of booting from a floppy disk, CD-ROM, and over the network. Let's start with MS-DOS and MS Windows.

As you know, when you turn on the computer, the POST (Power On Self Test) program starts first. It determines the amount of available memory, tests it, determines the presence of other components (keyboard, hard drive, etc.), initializes adapter cards. The screen usually displays messages about the amount of memory, about its testing, a list of detected devices (floppy and hard disks, processor, COM ports, etc.).

After testing is complete, POST calls Int 19h, which tries to find the boot device. The search is performed in the order defined in the Setup BIOS, and is carried out by polling the zero sectors of the corresponding devices. If the disk is bootable, then its zero sector contains the Master Boot Record (MBR). The last two bytes of the MBR are a “magic number”, which is an indication that this sector is MBR, and therefore the disk is bootable. In addition to the "magic number", the MBR contains the disk partition table, which was already mentioned above, and a small program - the primary loader, with a volume of only 446 (0 * 1BE) bytes.

Table 2.1 shows the structure of the master boot sector created during Windows installation.

Table 2.1 Structure of the Master Boot Sector

Interrupt 19h BIOS loads the primary bootloader into the computer memory and transfers control to this program. But such a small program cannot load the OS; all it can do is load a more powerful program into memory — the secondary loader.

To do this, it looks for the active partition in the partition table and reads the secondary loader into memory, which is located starting from the first logical sector of the active partition. Pay attention to the word “starting”. The point is that the secondary bootloader has different lengths on different systems.

The secondary loader loads the first layer of programs required to start the OS. In the case of MS - DOS, the loader program loads IO.SYS at 700h, then MSDOS.SYS and transfers control to the SYSINIT section of the IO.SYS module.

If for some reason no active partition is found on the disk, the boot process continues by processing interrupt 18h. This branch is rarely used in its entirety, but it can be very useful in some situations. In remote boot, when the OS is booted from the server, this interrupt is redirected by the POST program to the ROM of the network card.

Problems with large drives

In MS - DOS and the first versions of Windows, access to disks was organized through interrupt 13 (Int 13h) BIOS. In this case, the addressing of sectors on the disk was used based on the indication of the numbers of the cylinder, head and sector on the track (C / H / S). More precisely:

1) AH - selection of operation;

2) СР - lower 8 bits of the cylinder number;

3) CL - bits 7-6 correspond to the most significant bits of the cylinder number, bits 5-0 correspond to the sector number;

4) DH - number of the reading head;

5) DL - disk number (80h or 81h).

It should be noted that all the above restrictions are significant only at the stage of OS boot, since Linux itself and the latest versions of Windows no longer use BIOS interrupt 13 when working with disks, but use their own drivers for working with disks. But before the system can use its own driver, it must at least load it. Therefore, at the boot stage, any system is forced to use the BIOS. This causes restrictions on the placement of many systems beyond 8 GB, they cannot boot from there, although after a successful boot they can work with much larger disks. In order to understand how to get around these restrictions, we need some knowledge of how Linux boots.

LILO bootloader from Linux distribution

Before proceeding with the installation of the second OS, you need to choose a method for organizing the choice of OS at the stage of computer boot. Downloader programs solve this problem. There are several programs of this kind. Since we are talking about Linux, the first thing to mention is the LILO program, which is included with any Linux distribution.

LILO is a set of several programs: the bootloader itself, programs used to install and configure the bootloader, and service files:

The / sbin / lilo program, which runs under Linux, is used to write all the information needed at boot time to the appropriate places. It must be restarted every time a change is made to the kernel or the LILO configuration file;

Various service files that LILO needs at boot time. These files are usually located in the / boot directory. The most important of these are the bootloader itself and the map file (/ boot / map), which specifies the location of the kernel. Another important file is the LILO configuration file, which is usually /etc/lilo.conf;

The bootloader itself is the part of LILO that is first loaded into memory via a BIOS interrupt, and which loads the Linux kernel or the boot sector of another OS. The loader also has two parts. The first part writes to the boot sector and serves to load the second part, which is much larger in size. Both parts are usually stored on disk in the /boot/boot.b file.

The LILO boot sector can be placed in the following locations during system installation:

Boot sector of a floppy disk in Linux format (/ dev / fd0, ...);

MBR of the first hard disk (/ dev / had, / dev / sda, ...);

Boot sector of the primary partition of the Linux file system on the first hard disk (/ dev / hda1, / dev / hda2, ...);

The boot sector of the logical partition in the extended partition of the first hard disk (/ dev / hda5, ...). True, most programs like fdisk do not assume that it is possible to boot from an extended partition and refuse to declare it active. Therefore, LILO includes a special program (activate) to bypass this limitation. But the fdisk program from the Linux distribution supports the ability to activate an extended partition. To do this, either the -b option or the BOOT variable must be used.

The LILO boot sector cannot be placed in the following locations:

Boot sector of a floppy disk or primary partition, formatted in other file systems;

In a Linux swap partition;

In addition to the fact that LILO needs the following files at boot time:

- / boot / map (created when / sbin / lilo starts);

All bootable kernel versions (if you select a kernel version at boot time);

Boot sectors of other operating systems that will be loaded through LILO;

Messages issued at boot (if any)

When LILO boots up, it displays the word "LILO". In this case, the output of each letter indicates the completion of a certain action or stage of the LILO boot. If the download fails, then by the number of letters displayed, you can judge the cause of the problem.

Nothing is printed - no part of LILO has been loaded. Either LILO was not installed or the partition it is on is not active

L [error code] - the primary loader has loaded and started (control has been transferred to it), but it failed to load the secondary loader. The two-digit error code indicates the specific cause of the problem. This is usually due to media defects or incorrectly set disk geometry. Unless LILO stops at this point with an endless string of error codes, the problem is usually easy to fix.

LI - the primary loader was able to load the secondary loader, but failed to start it for execution. This could be caused by an error in setting the disk geometry, or by the fact that the /boot/boot.b file was moved without restarting / sbin / lilo.

LIL - The secondary loader started, but was unable to start the descriptor table from the map file. This is usually due to a defect on the disk or incorrect geometry of the disk.

LIL? - the secondary bootloader was loaded at the wrong address. Usually caused by an error in setting the disk geometry, or by moving the /boot/boot.b file without restarting / sbin / lilo.

LIL- - descriptor table destroyed. Usually caused by an error in setting the disk geometry, or by moving the /boot/boot.b file without restarting / sbin / lilo.

LILO - All LILO parts loaded successfully.

Init process and / etc / inittab file

As you know, after turning on the power of the computer and completing the testing of the hardware, the BIOS is read from the first sector of the boot disk, which the program is the bootloader. This program starts the main boot loader (such as LILO), which in turn loads the system kernel into memory, which is usually stored in the vmlinuz-x.y.z-a file in the / boot directory.

As soon as it boots, the kernel mounts the root filesystem and starts the init process. The init process is the program that is responsible for continuing the boot process and bringing the system from the initial state after kernel boot to the standard state of handling requests from many users.

The exact list of these operations depends on what is called the run level. The runlevel defines the list of actions performed by the init process and the state of the system after boot, i.e. configuration of running processes. The runlevel is identified by a single character. There are 8 main runlevels in Linux OS:

1) Stop the system;

2) Single-user mode (for special cases of administration);

3) Multi-user mode without NFS (the same as 3 if the computer does not work with the network);

4) Full multiplayer mode;

5) Use is not regulated;

6) Usually used to start the system in graphical mode;

S) (or s) - roughly the same as single user mode, but S and s are used primarily in scripts.

First of all, after starting, the init process reads its / etc / inittab configuration file. This file consists of separate lines. If the line starts with a # sign or is empty, then it is ignored. All other lines consist of 4 fields separated by colons:

id : runlevels : action : process

id - row identifier;

runlevels - run levels;

process - process;

action - action;

The action field contains a keyword that defines additional conditions for the command specified by the process field. Valid values for the action field:

respawn - restart the process if it terminates;

once - execute the process only once when moving to the specified level;

wait - the process will be launched once upon transition to the specified level;

sysinit - This keyword denotes actions performed during system boot regardless of the runlevel (the id field is ignored).

boot - the process will be launched at the stage of system loading from the runlevel;

bootwait - the process will be started at the stage of system boot from the runlevel, and init will wait for it to complete;

initdefault - the line in which this word appears in the action field defines the runlevel to which the system goes by default.

off - ignore this element;

powerwait - Allows the init process to stop the system when power is lost.

Ctrlaltdel - Allows init to reboot the system when the user presses a key combination ~~on keyboard.~~

This list is not exhaustive. For more information on the inittab file, see the init (8), inittab (5), and getty (8) man pages.

2 . Project part

2.1 Statement of the problem

It is necessary to study the theoretical material on the selected topic, develop an algorithm for the bootloader when implementing the method (presented in the form of a block diagram), and describe the algorithm.

2.2 Development of an algorithm for solving the problem

Input: Uniprocessor System, Application Program, LILO Loader, POST Program, Mutual Exclusion.

Figure 1 shows the algorithm for “loading an application program”.

Figure 2 shows the algorithm for "loading the Operating System"

2.3 Description of the algorithm for loading the application program

1) The application program is launched for execution. After that, the system program "Loader" is activated.

2) After activation, it starts scanning the RAM to find free areas.

3) If such areas are found, then the determination of the beginning of the address of the allocation of the free area begins. Then we go to this address and determine the size of the free area.

4) After that, the size of the code of the application program, which is launched for execution, is determined.

5) Compare the size of the code and the size of the free area in RAM.

6) If there is enough space in RAM to copy the application code, then the number of virtual pages of physical pages is installed in the page table. Then the application code is copied into RAM. And the end of the process.

7) Otherwise, we will find out if there is enough space in the RAM for a part of the application program code. If yes, then we repeat those actions when there is enough space for the complete code of the application program. But after copying the code into RAM, a part of the code is copied to the swap area.

8) If there is not enough space for a part of the code, then there is a transition to the stage of scanning the RAM to find free areas.

2.4 Description of the OS boot algorithm (Operating System)

1) The POST program starts. With the help of this program, the available memory is tested, the presence of other components (various PC devices, for example: keyboard, hard drive, etc.) is determined and the adapter cards are initialized.

2) After the program is running, POST is displayed on the screen about the results of its work.

3) We call the program 19H, which tries to find the boot device.

4) Interrupt 19H BIOS loads the primary bootloader into the computer memory and transfers control to this program

5) Due to the lack of power of this program, load the OS. She is therefore looking for a more powerful program that can do this - a secondary loader. To do this, it searches the partition table for the active partition and reads the secondary loader into memory.

6) Secondary loader loads the first layer of programs required to start the OS. The loader program loads the IO.SYS module at 700h, then MSDOS.SYS transfers control to the SYSINIT section of the IO.SYS module.

7) If, for some reason, an active partition was not found on the disk in the partition table, the boot process continues by processing interrupt 18h.

2.5 Description of the download algorithmUnixusing the bootloaderLILO

1) Run the program / sbin / lilo to write all the information needed at the boot stage to the appropriate places. Search for service files required by LILO at boot time.

2) If the files are not found, then a message about the end of the download is displayed.

4) If the primary loader failed to load the secondary one, then an informational message about an error during loading is displayed on the screen.

6) If the primary loader successfully loaded the secondary loader, but failed to start, then an informational message about an error during loading is displayed.

7) Otherwise, the secondary bootloader starts.

8) Check that the secondary bootloader is loaded at the correct address.

9) If not, then an informational message about an error during loading occurs.

10) Check if the descriptor table is corrupted. If yes, then an informational message about an error during loading is displayed. If not, then the descriptor table is loaded from the map file.

11) Checking whether the launch of the descriptor table was successful. If not, then output an informational error message at startup.

12) Otherwise, output an informational message about the successful loading of LILO.

Conclusion

In this course work, some aspects of loading programs are considered. Types of loaders: moving, primary, secondary, etc. The necessity of using the bootloader in various operating environments has been proven. Various boot methods are discussed, such as loading an application, booting with the LILO loader, and booting the OS. The theoretical material on the topic has been studied, algorithms for the loader operation have been developed when implementing the method (presented in the form of a block diagram).

References

1. Tanenbaum Andrew. Modern operating systems / Tanenbaum Andrew. - 2nd ed. - SPB .: Peter, 2002 .-- 1037s.: Ill. - (Classics Computer Science). - ISBN 5-318-00299-4

2. Partyka, T.L. Operating Systems, Environments, and Shells: A Tutorial for Environments. Prof. Arr. rivers. MO / Partyka, T.L, Popov, I.I. - M .: FORUM: INFRA - M, 2006. - 399 p.: Ill. - (Professional education). - ISBN 5-8199-0072-5-16-001355-5

3. Olifer, V.G. Network operating systems: Textbook. manual for universities of rivers. MO / Olifer, V.G, Olifer, N.A. - SPb .: Peter, 2003 .-- 538s.: Ill. - ISBN 5-272-00120-6

4. Trubacheva, S.I. Programming in operating systems: Methodological guide / Trubacheva, S.I. - Togliatti: VUiT, 2006 .-- 44p.

5. Terence Chan. System programming in C ++ for Unix / Ed. Kolomytsev. - Kiev, 2004.

6. Taket D., Barnet S. Special edition. Using LINUX / Per. from English - 4th ed. SPb .: Williams, 2003.

7. Ivanova G.S. C ++ programming / Textbook. Ed. M .: MGTU, 2002.