Jump to content

IFS - Remote IPL / Bootable IFS

From EDM2
Revision as of 03:55, 10 February 2020 by Martini (talk | contribs) (Created page with "{{IFSRef}} {{IBM-Reprint}} This chapter describes the OS/2 Version 2.0 boot architecture and extensions to the installable file system mechanism (IFSM) to enable booting from...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Installable File Systems for OS/2
  1. Installable File System Mechanism
    1. Installable File System Overview
    2. Extended Attributes
    3. FSD File Image
    4. FSD Initialization
    5. IFS Commands
    6. File System Function Calls
    7. FSD System Interfaces
    8. FSD Calling Conventions and Requirements
  2. FS Service Routines
  3. FS Helper Functions
  4. Remote IPL / Bootable IFS
  5. mini-FDS Entry Points
  6. mini-FDS Helper Routines

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

This chapter describes the OS/2 Version 2.0 boot architecture and extensions to the installable file system mechanism (IFSM) to enable booting from an FSD- managed volume, referred to as Bootable IFS (BIFS). If the volume is on a remote system, it is referred to as Remote IPL (RIPL).

The mini-FSD is similar to the FSD defined in this document. However, it has additional requirements for to allow reading of the boot drive before the base device drivers are loaded. These requirements are fully defined in the two interface sections of this chapter.

To satisfy its I/O requests, the mini-FSD may call the disk device device driver imbedded in OS2KRNL (BIFS case) or it may provide its own driver (RIPL case) .

Along with the mini-FSD, the IFS SYS Utility is required to initialize an FSD -managed volume with whatever is required to satisfy the requirements of the mini -FSD and this document.

The IFS mechanism includes some additional calls which the mini-FSD may need while it is linked into the IFS chain.

Operational Description

FAT Boot Procedure

The following figure represents the major stages of the OS/2 Version 2.0 FAT boot procedure.

•──────────•──────────•──────────•──────────•──────────•──────────•───────────→ time
   POST       BOOT        OS2BOOT    OS2LDR      stage1    stage2     stage3
             SECTOR       (OS2LDR                OS2KRNL
                           loader)

Figure 4-1. OS/2 Version 2.0 FAT boot procedure

Powering-on the machine or pressing CTRL-ALT-DEL causes control to get transferred to the power-on-self-test (POST) code. This code initializes the interrupt vectors to get to the BIOS routines. It then scans the I/O adapters looking for and linking in any code which exists on them. It then executes an interrupt 19h (INT 19 ) which causes control to be transferred to the disk or diskette boot code.

The INT 19h code reads the boot sector from disk or diskette into memory at 7C00H. Along with code, the boot sector contains a structure called the BIOS Parameter Block(BPB). The BPB contains information which describes how the disk is formatted. The boot code uses this information to load in the root directory and the FAT micro-IFS, which is kept inside the OS2BOOT file. After the micro-IFS is loaded the boot sector transfer control it via a far jump.

OS2BOOT receives pointers to the RAM copies of the root directory and the BPB . Using the BPB information, OS2BOOT loads in the FAT table from the disk. Then using the root directory and the FAT table, the OS2LDR file is loaded into memory from disk. The inclusion of this micro-IFS in the FAT boot process has removed the requirement that the OS2LDR file be logically contiguous on the FAT drive .

OS2LDR contains the OS/2 loader. It relocates itself to the top of low memory, then scans the root directory for OS2KRNL and reads it into memory. After the required fixups are applied, control is transferred to OS2KRNL, along with a pointer to the BPB and the drive number.

OS2KRNL contains the OS/2 kernel and initialization code. It switches to protected mode, relocates parts of itself to high memory, then scans the root directory for and reads in the base device drivers (stage 1). Once again, the BIOS interrupt 13h is used to read the disk, but mode switching must be done.

OS2KRNL then switches to protection level 3 and loads some of the required dynamic link libraries (stage 2) followed by the device drivers and FSDs specified in CONFIG.SYS (stage 3). This is done with standard DOS calls and, therefore, goes through the regular file system and device drivers.

BIFS Boot Procedure

The following figure represents the major stages of the OS/2 Version 2.0 BIFS boot procedure.


•──────────•──────────•──────────•──────────•──────────•───────────→ time
   POST     BlackBox    OS2LDR     stage1     stage2      stage3
            (Micro                 OS2KRNL
                FSD)

Figure 4-2. OS/2 Version 2.0 BIFS boot procedure

The major difference between this boot procedure and the FAT boot procedure is that there is no assumption of booting off of disk. OS/2 Version 2.0 does not define what should happen between when the POST code is run and when the OS2LDR program gains control.

When OS2LDR receives control, it must be passed information about the current state of memory and pointers to the Open, Read, Close, and Terminate entry points of the micro-FSD. Included in the memory map information is the positions of the micro-FSD, mini-FSD, RIPL data, and the OS2LDR file itself.

Note
This interface is defined in a next section of this chapter.

As with the FAT boot procedure, the OS/2 loader relocates itself to the top of low memory, and with the help of the micro-FSD, scans the root directory for the OS2KRNL file. After reading OS2KRNL into memory and applying the required fixups, control is transferred to the kernel.

When OS2KRNL receives control, it goes through the same initialization as before (stage 1) with a couple of exceptions. The module loader is called to load the mini-FSD from its memory image stored by OS2LDR in high memory to its final location at the top of low memory. Also, the mini-FSD is called to read the base device drivers (one at a time) through the stage 1 interfaces.

Before any of the dynalinks are loaded, the mini-FSD will be linked into the IFS chain (it will be the only link in the chain) and asked to initialize through FS_INIT. The FS_INIT call marks the transition from stage 1 to stage 2.

The dynalinks are then loaded using the stage 2 interfaces, followed by the device drivers and FSDs.

The mini-FSD is required to support only a small number of the FSD system interfaces (the FS_xxxx calls). Therefore, the first FSD loaded must be the replacement for the mini-FSD.

After the replacement FSD has been loaded, it is called at FS_INIT to initialize itself and take whatever action it needs to effect a smooth transition from the mini-FSD to the FSD. It then replaces the mini-FSD in the IFS chain, as well as in any kernel data structures which keep a handle to the FSD (for example, the SFT , VPB). This replacement marks the transition from stage 2 to stage 3.

From this point on, the system continues normally.