Tag Archives: os/2

The Warp Boot Sequence

Understanding the boot sequence of Warp is important to administrators and support personnel. It also helps to provide additional insight into the architechture of OS/2 Warp. Such an understanding will enable you to determine what can cause problems for your computer hardware as well as for Warp during boot.

Turning on the computer

When the computer is first turned on the power supply prevents the computer from taking any action by maintaining an electrical signal called “Power Good” in the off state until all power supply voltages have settled into the normal operational range. Only when the power supply is working correctly does it turn on the “Power Good” signal.

When the “Power Good” signal is turned on, some electronic circuitry in the computer sets the processor’s instruction pointer to the location in ROM BIOS which contains the POST program code. The computer loads the instruction at that location into the processor and starts the processor execution cycle. At this point the processor is in “Real” mode which means that it is effectively a fast 8086.

Power On Self Test

The Power On Self Test is located on a type of integrated circuit chip called Read Only Memory (ROM), along with some other programs such as BIOS. Power On Self Test (POST) is performed by most IBM PCs and PC compatible computers. POST is a critical part of the boot process because it provides some assurance that the hardware components of the computer are working correctly. Unfortunately, POST (and all DOS based diagnostic programs – there are no OS/2 based 32 bit diagnostic programs) is usually a 16 bit DOS class of program. It is therefore unable to test all aspects of a 32 bit computer. Even if POST or diagnostic programs were true 32 bit programs it would still be impossible to test every electronic circuit and component in a computer. At best a well written diagnostic program can only test about 80% of the components in a computer; POST, which is designed only to provide a quick check of the computer’s critical components does not even check that much. This means that there is still a good chance that a computer which passes both POST and diagnostics can still have a hardware defect which would cause problems with Warp or application programs.

POST first displays a count of installed memory as it performs a quick test of RAM. When that is complete you should see the total amount of RAM installed in your computer on the screen. Warp will recognize and utilize the amount of RAM displayed during the POST memory count.

If the memory count does not appear on the screen, it could be that the computer has been configured not to perform POST, the display is defective, or that the computer has a defective power supply. If the memory count does not show up on your screen, replace the display with one which is known to be good, and ensure that the computer has been configured to perform the POST. If that does not resolve the problem, replace the power supply.

POST then Initializes some interrupt vectors, and loads BIOS into RAM where it will perform better than if it were left in ROM. ROM is not only slower than RAM, but also it can only be read 8 bits at a time. When copied to RAM, BIOS can be read 16 bits at a time. Remember that POST is a 16 bit program, not 32 bit, and the processor is still in Real mode which means that it cannot execute 32 bit instructions or data transfers.

Next. the Power On Self Test scans for I/O adapters and links the adapter BIOS code into the system BIOS from ROM. It is at this time that you will see the BIOS code for your Adaptec SCSI adapter, for example, loaded. Hardware adpater conflicts may cause hangs during this part of POST. If you see the memory count and other messages on your screen during POST but POST never completes, you probably have an adapter conflict. You can tell that POST has not completed because the computer will not beep. If POST completes, whether successfully or with errors, it always produces one or more beeps.

After the BIOS code for the various I/O adapters has been integrated, the computer’s loadable ABIOS is refreshed, if it has one. Some computers have ABIOS, but many do not. Again, ABIOS is an Advanced BIOS which is capable of supporting a true multitasking operating system.

This normally completes POST and, if there were no errors detected, POST causes the computer to produce one short beep. Of course, if you observe any error messages on the screen, or POST beeps any other beep or combination of beeps, the computer has a hardware problem which should immediately be repaired.

Loading the Bootstrap program

The word “boot” is a short form of the term “bootstrap”. It refers to the fact that computers are really incapable of performing an action of any kind without a program of some sort to help them do it. Computers are so dumb that without some help they cannot even start themselves. To overcome this problem, designers have developed small programs called bootstrap loaders which enable it to “pull itself up by the bootstraps” and become smart enough to find and load the operating system. This bootstrap loader is located on the boot sector of the hard drive.

After POST completes with the “OK” beep, it issues an interruupt 19h to BIOS. BIOS interrup 19h searches for a boot sector on the disks specified in the computer’s boot sequence. Interrupt 19 loads into RAM the first boot sector found in the boot sequence into memory location 7C00h and transfers control of the computer to the bootstrap loader.

If no valid, bootable boot sector is found on any of the disks in the boot sequence, the boot sector contains a little bit of code which displays an error message. If the disk (or diskette) was formatted by OS/2, one of the following messages is presented.

OS/2 !! SYS01475
OS/2 !! SYS02027

or

The file OS2LDR cannot be found. Insert a system diskette and restart the system

If the disk (or diskette) was formatted by DOS, the following message is presented.

Non-System disk or disk error
Replace and strike any key when ready

All of these messages mean exactly the same thing: a valid boot record cannot be found. Refer to “OS/2 !! SYS01475 error message” for more details and how to recover.

If a valid boot block is found, it is loaded into RAM and control of the computer is turned over to it.

OS2BOOT Loads the operating system loader

The OS/2 Boot block finds and loads OS2BOOT. The Boot block is very small – only 16 blocks (sectors) in size. Because of this it is not very smart. One of the issues for the operating system at this time is that the HPFS drivers are not yet loaded, but the Boot block needs to be able to locate the OS2BOOT file on the HPFS volume. To enable this to happen, the Boot block uses a micro HPFS which enables it to locate files in the root directory. The boot block loads the OS2BOOT file.

OS2LDR loads the operating system

The OS2BOOT file and the OS2LDR both use a min-HPFS file system that is larger and more complex than the micro-HPFS file system used by the Boot block which can read the root, \OS2 and \OS2\BOOT directories. The OS2BOOT file loads the OS2LDR file and transfers control of the system to it.

OS2LDR in turn loads OS2KRNL which is the kernel of the operating system. Control is transferred to the OS2KRNL and the first OS/2 logo and copyright message is displayed during kernel initialization. The kernel is still using the mini-HPFS file system.

Processing the CONFIG.SYS file

The OS2KRNL reads the CONFIG.SYS file and begins processing of the statements in a combination sorted and native (unsorted) sequence. The CONFIG.SYS statements are processed in order shown below.

BASEDEV statements in the following order:

SYS
BID
VSD
TSD
ADD
I13
FLT
DMD

At this point, the OS/2 Logo changes to “Loading, please wait…”.

IFS statements are processed. The HPFS file system must be first IFS installed because the first one listed in the CONFIG.SYS file in native order replaces the mini-HPFS.

AUTOCHECK runs HPFS if the dirty file system flag is set.

DEVICE= statements processed.
CALL= statements processed.
RUN= statements processed.
Other statements are processed.
SET variable statements are processed.

All of the device drivers loaded at this time. A Trap error in a device driver can cause system hang at this point.

The program specified by PROTSHELL= statement is started. This is the Graphical Programming Interface which enables OS/2 to support a GUI workplace shell.

STARTUP.CMD and the Workplace Shell are started

The STARTUP.CMD is started if one is present.

If SET AUTOSTART=FOLDERS is specified in the CONFIG.SYS file, then theWorkplace Shell is started. All previously open folders will be opened. Desktop objects are displayed.

If SET AUTOSTART=PROGRAMS is specified in the CONFIG.SYS file, then Program objects which were open at shutdown are restarted.

If SET AUTOSTART=CONNECTIONS is specified, then network objects active at shutdown will be restarted. This may cause the logon prompt to be displayed.

The Boot process is complete

The system is now up and running under user control.