Creating a Bootable CD-ROM for OS/2
- Date
- 11/29/1998
- File
- cdboot.zip
This package is the result of what started as a simple search to find a way to create an emergency bootable CD for OS/2, and ended up taking a tremendous amount of time before I was able to contact some key people and obtain help in accomplishing my goal. The following discussion outlines the procedures to follow and the files required to create a CD that can be booted to IBM's OS/2 Warp operating system.
The ability to create a bootable CD-ROM was established in a specification developed by:
and known as the "El Torito" Specification. For the first time, there was a uniform way to create a bootable CD. However, this format was best suited to real mode MS-DOS, because it was based upon the use of built-in access in the BIOS of a motherboard, or on a hard drive controller. The BIOS's of these devices operate solely in real mode.
The specification outlined by Phoenix Technologies and IBM allows the creation of a single entry boot image, or multiple boot images, with the option of which image to utilize made available to the user. This discussion will only deal with user available options.
BOOTABLE OS/2 CD-ROM
When creating a bootable CD for OS/2 Warp 3 Server, IBM was faced with the protected mode boot process of OS/2. In that process, the operating system first loads the kernel using standard BIOS calls, then loads the protected mode floppy driver, the protected mode hard drive controller driver, and all the other specific device drivers. Finally OS2DASD.DMD is loaded, which then takes control of the drives through the protected mode drivers. The process is roughly as follows:
BIOS -> reads Master Boot Record (MBR) of each HD + Boot Volume Descriptor (BVD) of CD -> if BVD exists, boot from CD by loading BVD and obtain address of bootable image -> else boot from HD -> load MBR of bootable image -> MBR bootstrap program loads OS2BOOT -> loads OS2LDR -> loads OS2KRNL -> reads config.sys -> loads all BASEDEV= drivers for floppy, HD/CD devices (ibm1flpy; ibm1s506, ibmidecd.flt for IDE devices; aic7870.add for SCSI devices) -> loads OS2DASD -> OS2DASD stops using BIOS to load files, and starts using protected mode floppy and HD drivers-> loads country.sys and *.DCP files -> In the order they appear, loads DEVICE= drivers (OS2CDROM.DMD) and Installable File Systems (IFS) (HPFS, CDFS) -> load rest of necessary files.
Here is where the problem starts: because the installable CD file system has not yet been loaded, the DASD manager cannot recognize the CD. The El Torito Specification is specifically set up to fool the system to "think" that it is booting from a floppy, but DASD doesn't check for this, instead, DASD goes directly to the protected mode floppy driver and requests the continued load of the system, normally starting with country.sys and the *.DCP files. The installable CD file system is not loaded until after DASD takes control, so there is no way the system can know how to read from the CD, or even that is should read from the CD. Imagine the system's surprise when the floppy driver says there is no diskette in the drive, and the system doesn't have anywhere to obtain the rest of the files to be loaded. Sudden death, and the system stops.
To solve this, IBM could have modified either OS2DASD.DMD, or the floppy driver, to use the BIOS interrupts for just a little longer. There is a documented interrupt 13 function that would tell the system that it is running from a CD, and that would allow the system to use the BIOS a little longer. Instead, IBM developed a filter driver, loaded before OS2DASD.DMD, that checks the CDROM drive detected by the protected mode drivers to see if there is a telltale "El Torito Specification" (BVD) signature, and if there is, emulates the BIOS load from the CD long enough for the system to initialize the CD driver and file system, and thus be able to complete the loading from the CD. This may seem like overkill, but the record of manufacturers and BIOS developers is probably uneven enough that IBM simply could not be certain that all of the El Torito Specification modifications had been properly made to the motherboard or drive controller BIOS's. In that way, IBM could have a system that depended on the BIOS only enough to get the boot started, and if it wasn't capable of telling OS/2 that a CD was the boot device, it didn't matter. The process becomes:
BIOS -> reads Master Boot Record (MBR) of each HD + Boot Volume Descriptor (BVD) of CD -> if BVD exists, boot from CD, else boot from HD -> load BVD and find address of bootable image -> load MBR of bootable image -> MBR bootstrap program loads OS2BOOT -> loads OS2LDR -> loads OS2KRNL -> reads config.sys -> loads all BASEDEV= drivers for floppy, HD/CD devices (ibm1flpy; ibm1s506, ibmidecd.flt, for IDE devices; aic7870 for SCSI devices) -> [loads cd_boot.flt for CD boot with other BASEDEV= drivers] -> loads OS2DASD -> OS2DASD stops using BIOS to load files, [and allows cd_boot.flt to continue the load of the floppy boot image from the CD until the following two steps are completed,] -> cd_boot.flt loads: country.sys and *.DCP files -> In the order they appear, loads DEVICE= drivers (OS2CDROM.DMD) and Installable File Systems (IFS) (CDFS, HPFS) -> OS2DASD then starts using protected mode floppy and HD drivers, -> load rest of necessary files.
The [ ] bracketed clause describes what has been added to allow booting from the CD.
There are some apparent side effects of this decision. The developer of the CD boot filter was never able to get a system operational with a multiple boot image CD, or at least he only got it to work with the default boot image. Additionally, it never worked with multiple session CD's, those that were basically written using the XA specification, allowing more than one data session to be burned. CD sectors are numbered on a absolute basis, starting with sector 0, the first one, and incrementing by one for each sector. When a multiple sessions are written, there are some unused areas of the CD between sessions that are unreadable, and there is also some space used for the next session Table of Contents (a misnomer, because it only tells the CD where the next session starts, and what the first useable sector number is.) Thus, the last session does not restart numbering sectors at 0, it simply starts after the last session and the large sector gap after the last session. On the Unite CD Maker software package, this unused space is equal to 11,400 CD sectors between the first and second sessions (23.3 Megs, since a CD sector is 2048 bytes) and 6,900 sectors between each additional session (14.1 Megs). Each software package probably creates a slightly different size gap, so there is not a way for OS/2 to do any absolute sector reads without a lot of code to accommodate these requirements.
The El Torito Specification states that the sector used for setting up a CD boot must be on the LAST track of the CD, but at the time the CD filter software was written, it was apparently only designed to enable IBM to create a bootable CD for Warp Server. Since this was a production system, there was probably no need to spend the time to enable the driver to account for multiple sessions.
Keeping these limitations in mind, it is possible to create a bootable OS/2 CD, if the right drivers can be obtained. The CD boot driver is used by IBM and Compaq to boot new servers when first installed, after choose which operating system is to be installed. The driver has not been released, but Sam Detweiler, Senior Technical Staff Member involved in the hard disk drivers, indicated he is trying to get the driver released, or even incorporated in some way into Adaptec's Easy CD Deluxe CD mastering software. To date, with little success.
I was able to obtain a copy of Warp Server, which has a bootable OS/2 system on it. The bootable image is Warp 3, but the necessary files will work just as well in Warp 4. Amazingly, once the proper steps have been taken to create the bootable image and the total CD image, the only things that need to be changed are the config.sys file on the bootable floppy image, the addition of one of two specific versions of IBM's IDE CD filter driver and, finally, the CD boot filter driver, all in the proper locations in the boot sequence. With the proper files available, let's see what it takes to create a bootable OS/2 CD, trying, if possible, to use nothing but OS/2 programs. First, however, I'll describe the configuration that must take place prior to actually burning the CD.
STEPS FOR CREATING BOOTABLE OS/2 CD'S
A. Create a 2.88 Meg floppy with the necessary files to boot to OS/2. This floppy will have the files that tell your system whether you want to boot to a command line session, a PM session, or a WPS session. It will determine your video resolution, the locations of your Desktop, if one is enabled, your Swapfile, and your system and user ini files. As in any normal bootable floppy, it will also have the basic OS2KRNL and all of the required floppy, hard drive and CDROM drivers.
B. Make an image of the floppy for use on the CD. (If multiple boot option desired, create A and B for each separate image)
C. Create a "boot catalog" for the CD. *
D. Create an ISO image of the CD; the boot floppy image and the boot catalog will be files that you include as part of this image.
E. Modify, if necessary, the ISO image to have the BVD and boot catalog properly point to the correct files. *
F. Burn the modified ISO image onto the CD.
- - optional step, depending upon software utilized.
A. Creating the Floppy Image (Required)
The El Torito Specification allows the CD to boot from one of the following types of images:
- Floppy
- 1.2 Meg
- 1.44 Meg
- 2.88 Meg
- Hard Drive
- any size less than the CD capacity
- No Emulation
- direct load of bootstrap code. Microsoft's NT loads this way: NTLDR is loaded into memory and determines if it was loaded from a CD or from a hard drive (apparently), and controls the boot process from there. This is not implemented in OS/2 by IBM.
For OS/2, only the 2.88 Meg floppy image and the hard drive images work with the drivers available. As noted above, the key to an OS/2 CD boot is the cd_boot.flt driver, which continues the load from the CD until the CD file system stack is initialized and os2cdrom can load the image using the protected mode drivers. This filter driver only works with a 2.88 Meg floppy image, it was not designed to utilize 1.2 or 1.44 Meg floppy images for booting. At this point, you are probably wondering how to boot from a hard drive, because cd_boot.flt only handles 2.88 Meg floppies. You simply remove all device specific drivers for hard drives (any *.add file), and insure that ibmint13.i13 is loaded instead. (This driver can only control a device through a controller that has a BIOS, either on the motherboard or on the controller itself.) Ibmint13.i13 runs in a small VDM session that uses the BIOS to control the drive controller(s) that are unclaimed by any prior drivers. With this in control, the boot process is supposed to proceed. (I haven't tested it, but that was what I was told by the author of cd_boot.flt.) The hard drive image becomes drive C:, and all your normal hard drives are moved back one drive letter. I.e., normal C: becomes D:, D: becomes E:, etc..
The easiest way to get a bootable OS/2 floppy image is to use BootOS2, IBM employee written software designed to create bootable floppies or bootable hard drive images. This will create a command line based floppy for booting your specific system, but the actual differences between that and either a PM or WPS session are minimal for our purposes. Once you have a bootable floppy created, you are ready to modify it with the proper config.sys, and add the cd_boot.flt to it. If you don't have a 2.88 Meg floppy, you are not totally out of luck. You should search the Hobbes repository for the file svd117.zip. This is the Super Virtual Disk driver for OS/2. With it, you can create any size drive in memory, but for this we are talking about a 2.88 Meg floppy. With this running , you should be able to create your bootable floppy, modify it, and then create the floppy image. The instructions for this program are in that zip file, but basically, you set up a virtual disk in memory, and tell bootos2 to use that "virtual disk" for your floppy disk, and it should then create the bootable floppy image you want, which you can then transfer to the boot floppy image, as discussed in B. below.
- Config.sys and the Required Files
I have included a copy of the original config.sys file from the Warp 3 Server bootable CD, as config.w3. Peruse it at your leisure. In addition, there is a copy of my config.sys file, config.w4, and it is reproduced below, with comments to show the essential elements of the file.
- Warp 4 Config.sys for a Bootable CD
BUFFERS=99 [I am simply copying the Warp 3 Server CD on these commands] IOPL=YES DISKCACHE=D2,LW PROTECTONLY=NO PAUSEONERROR=NO [If I screwed up, don't bother to wait for me to tell you to keep going.] RESERVEDRIVELETTER=W: [This command tells the system to assume all drive letters up to and including W are taken. This has the effect of moving the first CD drive to drive number X: NOTE, this command was added to Warp 3 via some fixpak, but appears to have been in Warp 4 from the beginning.] LIBPATH=.;\;Y:\OS2;Y:\OS2\dll;Y:\OS2\mdos;X:\W4OS2\DLL;X:\W4OS2\MDOS;A:\; SET PATH=Y:\os2;Y:\os2\mdos;X:\W4OS2;X:\W4OS2\MDOS; SET DPATH=Y:\os2;Y:\os2\mdos;X:\W4OS2;X:\W4OS2\MDOS; [X: is the bootable CD, Y is the virtual disk that I set up later. For two CD's, you would change Y: to Z:.] [Standard set up to create a swap file on the virtual disk, and use the standard keyboard drivers, with the default codepage, and video set up for VGA.] MEMMAN=SWAP,PROTECT [Why allow swapping on a virtual disk? See comments below.] SWAPPATH=Y:\ 512 COUNTRY=001,\COUNTRY.SYS CODEPAGE=437,850 DEVINFO=KBD,US,A:\KEYBOARD.DCP [Load these from the floppy.] DEVINFO=SCR,BGA,A:\VIOTBL.DCP SET VIDEO_DEVICES=VIO_VGA SET VIO_VGA=DEVICE(BVHVGA) [Standard Warp 4 drivers.] BASEDEV=PRINT01.SYS /IRQ BASEDEV=IBMKBD.SYS BASEDEV=IBM1FLPY.ADD /FORCE:1 /U:0 /F:2880 [See discussion below for rationale for these command line options.] BASEDEV=IBM1S506.ADD [standard IDE driver - add any command line options you use] BASEDEV=AIC7870.ADD [Adaptec 2940 PCI SCSI driver] BASEDEV=IBMINT13.I13 [failsafe BIOS driver] BASEDEV=OS2DASD.DMD [Controls all spinning magnetic media - floppies and hard drives] BASEDEV=OS2SCSI.DMD [for SCSI systems] BASEDEV=OS2ASPI.DMD /SHARE [You don't need this, I use it for other programs I load on my CD.] BASEDEV=XDFLOPPY.FLT [Well, you might need to access these floppies, if not, delete this.] BASEDEV=IBMIDECD.FLT [Critical File - See discussion below for the correct file to use.] BASEDEV=CD_BOOT.FLT /D:2 [THE Critical File - See discussion of command line options.] [Extra drivers for those specific hard drive controller adapters that are capable of booting from a CD. Delete the ones you don't need. There may be others, these are the only ones I am aware of.] basedev=aha154x.add [Only later 1542C versions will boot CD's.] basedev=asc.add [Advansys] basedev=flashpt.add [Buslogic] basedev=ini910u.add [Initio board - SIDE?] basedev=ql510.add [QLogic] basedev=sym8xx.add [Symbios Logic 53C8xx boards] basedev=tmscsim.add [Tekram SCSI] basedev=tmscsiw.add [Tekram UW SCSI] [Standard IBM filters for SCSI CD's that only use SCSI I commands. Delete the ones you don't need.] basedev=chincds1.flt basedev=hitcds1.flt basedev=neccds1.flt basedev=sonycds1.flt basedev=toshcds1.flt [CD ROM control and file system. Please note, I use the very latest CDFS that is supposed to be Joliet file system capable.] DEVICE=\OS2CDROM.DMD /Q [/Q - Don't bother me with feedback on my screen.] IFS=\CDFS.IFS /Q /W [/W enables Joliet file system] [At this point, we are now loading files from the CD using native mode drivers, and we don't need CD_BOOT.FLT anymore!] DEVICE=X:\W4OS2\DOS.SYS DEVICE=X:\W4OS2\MOUSE.SYS DEVICE=X:\W4OS2\POINTDD.SYS DEVICE=X:\W4OS2\PMDD.SYS IFS=X:\W4OS2\HPFS.IFS /CACHE:64 /CRECL:4 /AUTOCHECK:C [Note: you can load this from the CD. Putting it there saves space on the boot floppy image. ] [These DOS drivers are optional - I put them here only because IBM did on their CD; delete if you don't need DOS programs.] DEVICE=X:\W4OS2\MDOS\VEMM.SYS DEVICE=X:\W4OS2\MDOS\VXMS.SYS /UMB DEVICE=X:\W4OS2\MDOS\VDPMI.SYS DEVICE=X:\W4OS2\MDOS\VDPX.SYS DEVICE=X:\W4OS2\MDOS\VCDROM.SYS DEVICE=X:\W4OS2\MDOS\VMOUSE.SYS DEVICE=X:\W4OS2\MDOS\VVGA.SYS [More DOS related settings] FCBS=16,8 RMSIZE=640 DOS=LOW,NOUMB SHELL=Y:\OS2\MDOS\COMMAND.COM Y:\OS2\MDOS DEVICE=X:\W4OS2\VDISK.SYS 3584,512,512 [The virtual disk driver - See IBM Warp documentation for options] [The next program allows you to pause the system during the boot, and run a command line session] CALL=X:\W4OS2\CMD.EXE /C "X:\W4OS2\IPLPAUSE.EXE 15" & EXIT [Here is where you determine whether you are invoking a command line session, a PM session, or a WPS session. I identify the directory with booting files as being under the W4OS2 directory.] PROTSHELL=X:\W4OS2\PMSHELL.EXE [ For PM or WPS; for command line, use PROTSHELL=...\BOS2SHL.EXE] SET OS2_SHELL=X:\W4OS2\CMD.EXE [Same for command line, PM or WPS] SET RUNWORKPLACE=X:\W4OS2\MSHELL.EXE [not needed for command line; use PMSHELL.EXE for WPS, here I use EWS program mshell.exe to have a small footprint PM shell but don't have all the bells and whistles of the Desktop.] [Ini files are set up according to where the system boots. Using makeini.exe and the sample *.rc files supplied with OS/2, I created the following ini files: For user.ini files - X - the drive number of the boot device; Q (or "?") means that the system looks for the drive with the Desktop on it, and updates that Desktop. For sys.ini files, the first letter is the boot drive, and the second letter is where the swap file is, here the virtual disk.] SET USER_INI=Z:\OS2\XQ_USER.INI SET SYSTEM_INI=Z:\OS2\XY_SYS.INI SET AUTOSTART=TASKLIST,FOLDERS [For WPS only] SET KEYS=ON SET COMSPEC=X:\W4OS2\CMD.EXE [For command line, PM, WPS] SET HELP=Y:\os2;X:\W4OS2; SET PROMPT=[$p] SET KEYS=ON SET GS_LIB=X:\GSCRIPT\GS5.10:X:\GSCRIPT\GS5.10\FONTS [I include a copy of Ghostscript, a postscript and pdf file reader] [Helps load various drivers, supposedly] DEVICE=X:\W4OS2\TESTCFG.SYS [Here is where I set up my virtual disk and copy some essential files to it.] CALL=X:\W4OS2\CMD.EXE /C MD Y:\OS2 & COPY X:\W4OS2\CMD.EXE Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\XCOPY.EXE Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\XQ_USR.INI Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\XY_SYS.INI Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C MD Y:\OS2\MDOS & COPY X:\W4OS2\MDOS\COMMAND.COM Y:\OS2\MDOS >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\MDOS\DOSKRNL Y:\OS2\MDOS >NUL CALL=X:\W4OS2\CMD.EXE /C MD Z:\OS2\DLL & COPY X:\W4OS2\DLL\SESMGR.DLL Y:\OS2\DLL >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\DLL\BVSCALLS.DLL Y:\OS2\DLL >NUL RUN=X:\W4OS2\BOS2REXX.EXE [BootOS2 file to allow use of REXX]