Found via Limewire P2P – real nugget

The following figure represents the various major stages during the non-FAT boot procedure.

|------|---------|--------|----------|--------|--------|---------> time
  POST   "black    OS2LDR  OS2LDR.MSG stage1   stage2   stage3
	        box"                      OS2KRNL->

In order to enable both bootable IFS and remote IPL, the boot architecture is modified to assume nothing about the sequence of events from the time when POST executes the interrupt 19h to the time OS2LDR receives control (ie. the “black box” is running). However, it does assume that the micro-FSD and the mini-FSD are in memory when OS2LDR is given control. The normal memory map is as follows:

	    +-------------+ Top of High Memory
	    |   unused    |
	    +-------------+ 100000h (1Meg)
	    | ROM/screen  |
	    +-------------+ Top of Low Memory
	    | 64k unused  |
	    +-------------+ Top of Low Memory - 64k
	    |  microFSD   |
	    +-------------+
	    |   unused    |
	    +-------------+
	    |   OS2LDR    |
	    +-------------+ 10000h (64k)
	    |  mFSD.FSD / |
	    |  RIPL data  |
	    +-------------+   800h (2k)
	    |  reserved   |
	    +-------------+  0

The memory layout can vary but must be described by information passed to OS2LDR in the following table:

OS2LDR scans and saves the directory entries for OS2KRNL and OS2LDR.MSG from the root directory. After the directory entries have been saved, the OS2LDR.MSG file will be loaded and parsed into
two separate modules (resident vs. discardable messages). The memory configuration will be as follows:

	    +-------------+ Top of High Memory
	    |   unused    |
	    +-------------+ 100000h (1Meg)
	    | ROM/screen  |
	    +-------------+ Top of Low Memory
	    | 64k unused  |
	    +-------------+ Top of Low Memory - 64k
	    |  microFSD   |
	    +-------------+
	    |   unused    |
	    +-------------+
	    | OS2LDR.MSG  |
	    +-------------+
	    | Discard msgs|
	    +-------------+
	    |Resident msgs|
	    +-------------+
	    |   OS2LDR    |
	    +-------------+ 10000h (64k)
	    |  mFSD.FSD / |
	    |  RIPL data  |
	    +-------------+   800h (2k)
	    |  reserved   |
	    +-------------+  0

OS2LDR will then relocate the mini-FSD to high memory (above the 1-Meg boundary but below 16 meg), then continue on with the same initialization before transfering control to OS2KRNL. The resulting memory configuration is as follows:

	    +-------------+
	    |    free     |
	    +-------------+ 16M
	    |  RIPL data  | (non-FAT boot only)
	    +-------------+
	    |  mFSD.FSD   | (non-FAT boot only)
	    +-------------+
	    |    free     |
	    +-------------+
	    | OS2KRNL(hi) |
	    +-------------+
	    |    free     |
	    +-------------+ 1Meg
	    | ROM/screen  |                       +------------------+
	    +-------------+ Top of Low Memory     | OS2LDR (Discard) |
	    |   OS2LDR    |----------->---------->+------------------+
	    +-------------+                       |   Discard Msgs   |
	    |    free     |                       +------------------+
	    +-------------+
	    | OS2KRNL(lo) |                       +------------------+
	    +-------------+                       |  Resident Msgs   |
	    |  DosHlpSeg  |----------->---------->+------------------+
	    +-------------+ 1000h                 |    DosHlpSeg     |
	    |  reserved   |                       +------------------+
	    +-------------+ 0

When OS2KRNL receives control. 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). The module loader will be 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 will be called to read the base device drivers (one at a time) via the stage 1 interfaces.

The mini-FSD will be linked into the IFS chain (actually, it will be the only link in the chain.) and asked to initialize via FS_INIT. The FS_INIT call marks the transition from stage 1 to stage 2.

Further loading is then by using the stage 2 interfaces. Note that file handles are lost from stage 1 to stage 2.

The mini-FSD is required to support only a small number of the functions of an FSD. Therefore, the first FSD loaded must be the replacement for the mini-FSD.

After the replacement FSD has been loaded, it will be 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. The FSD will then replace the mini-FSD in the IFS chain, as well as in any kernel data structures which keep a handle to the FSD (ie. SFT, VPB).

From this point on, the system continues normally.