From: slavotinek@gmail.com   
      
   As a follow-up to a back-channel discussion with Louis, here is a short   
   primer on how the ROM-resident Stage 1 POST handles the IML process.   
      
      
   *Introduction*   
   ==============   
      
   I'll focus primarily on the Type 1 Complex here, but the presented   
   information applies to most, if not all, other IML-based PS/2s. Some   
   parts also apply to the flash-based (non-IML) systems that use a   
   modified version of this process to locate the Reference/Convenience   
   partition.   
      
   First of all, there are two major versions of the POST IML procedure:   
      
   1) The original implementation can only load an IML image from a floppy   
   drive or the first hard drive (limited to 1GB). The T0, early T1, and   
   early T2 complex ROMs use this method.   
      
   2) The later implementation, sometimes called "search IML," is more   
   flexible and can acquire the IML image from any SCSI hard drive (limited   
   to ~4GB) or from a floppy drive. This is used by the "enhanced" T1 and   
   T2 ROMs and the T3 complex ROM.   
      
   All T1 system ROMs contain IBM SCSI extensions consisting of the   
   "standard" Int 13 routines and a proprietary Int 4Bh func. 80h - "IBM   
   SCSI interface." This iface provides extended SCSI services, incl. SCB   
   (Subsystem Control Block) support.   
      
      
   *The Original Implementation*   
   =============================   
      
   While the advanced SCSI features are present even in the old T1 ROMs,   
   the POST/IML code does not reference them.   
      
   The IML routine starts by checking the first floppy drive for a   
   compatible IML record. If this succeeds, the Stage 1 POST ends by   
   calling the boot sector (which then loads the IML image file from the   
   disk, etc.).   
      
   If the floppy method fails, POST checks the planar ID to identify the   
   machine and decide how to continue. If it detects the Model 90 planar,   
   it installs the embedded ESDI BIOS extensions and uses the Int 13h   
   routines to check for an IML record on the first DBA ESDI drive. [Yes,   
   it should be possible to IML from a DBA ESDI drive on an early Model 90   
   with one of the "non-enhanced" T1 BIOS ROMs. The same is true for the T0   
   complex, where the ESDI install happens unconditionally - no planar ID   
   check is needed since it was only available with Model 90. It's another   
   question whether the system programs can install the IML partition on an   
   ESDI drive in the first place.] If the ESDI BIOS installation doesn't   
   finish successfully (no drives?), or if it fails to adjust the reference   
   partition "fencing" (by using somewhat proprietary Int 13h func. 1Fh   
   calls), it moves on to the SCSI subsystem.   
      
   The IML routine code allocates EBDA block for SCSI variables, and if not   
   already present in memory, it installs the embedded SCSI ROM extensions.   
      
   If ESDI or SCSI was successfully initialized, the POST uses the standard   
   Int 13h iface to read the first three sectors of the system partition   
   from the first hard drive. If a compatible IML record is found, POST   
   Stage 1 ends by calling it.   
      
   If the hard drive IML load fails, the system re-checks the floppy drive   
   for an IML record. If not found, the system prints an IML error and   
   finally halts.   
      
      
   *The Enhanced Implementation w/ Search IML*   
   ===========================================   
      
   The revised IML differs right from the get-go. It begins by allocating   
   the SCSI EBDA block and installing the SCSI extensions (if they weren't   
   installed previously). If this completes successfully, POST uses the   
   proprietary Int 4Bh SCSI iface to determine how many drives are   
   installed and what type they are. Usable drives are then checked for a   
   reference partition. This differs from the original implementation,   
   where the floppy and ESDI drives are checked first. In fact, ESDI   
   extensions are entirely missing from the "enhanced" ROMs.   
      
   POST then finally checks the first floppy for a compatible IML record,   
   and if it finds one, it ends by loading it.**   
      
   If that fails, it proceeds by checking the previously detected SCSI   
   drives for compatible records.** SCB calls are used to remove the IML   
   partition "fencing" (unlike the original implementation that used Int   
   13h func 1Fh calls to achieve this).   
      
   If the SCSI method doesn't succeed, it falls back to the floppy   
   subsystem (like in the original implementation), checks for IML there,   
   and if even that fails, it prints an IML error and halts.   
      
   (** Note: I don't have that part of the code fully reversed yet, but I   
   think this revised IML routine not only skips incompatible IML records   
   but also looks for the latest IML revision across all drives.)   
      
      
   *Conclusion*   
   ============   
      
   As you can see, IBM used proprietary BIOS functions in the IML code.   
   That is the main reason why the process fails on non-IBM controllers.   
      
   The original IML implementation relies largely on standard BIOS calls   
   but uses a few undocumented functions - namely, the Int 13h func. 1Fh   
   calls used to manipulate the IML fencing.   
      
   The "enhanced" method depends heavily on IBM-proprietary interfaces -   
   Int 4Bh and SCB, moving even further away from what was considered   
   "standard." On the other hand, these new interfaces no doubt simplified   
   the implementation of the otherwise relatively complex "search IML"   
   system. They may also be behind the raised IML drive capacity limit   
   (I'll look into it...).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)