Study of the OS/2-eCS Boot Process
My main point of curiosity is the operation of the os2ldr file and I found that it is hard to get far without understanding the steps getting to executing os2ldr. The point leading up to os2ldr is considered the "Black Box" because there are a number of ways to boot eCS-OS/2 for example FAT, IFS, or Remote IPL. The major issue is that the "Black Box" sets up the system and provides all
information os2ldr requires.
Just for by own interest I pulled the MBR from my eCS 2.0 RC4 driving using
DFSee and disassembled. What follows is the result and some comments from noted sources. Since I am not very good at reading decompiled code I went to the next level, trying to step through the boot using a MBR, BPB and os2boot running in
Bochs on my one of my Linux systems.
I found an old 630 meg IDE hard drive and installed in the system. The system was booted using the current eCS 2.0 RC4 CD. I then ran LVM and made bootable compatible partition and wrote the MBR. Next, I did a long JFS format of the partition and then ran sysinstx.com against it to get os2boot installed. I did forget to set the partition active, but later corrected using DFSee. The hard drive was pulled and install in my LINUX system and I used dd to image the drive.
This image will boot through the running of os2boot, but will quit due to the lack of an os2ldr file. That will come later. So if anyone is interested the image can be downloaded here:
harddrive.zip When setting up in Bochs the correct drive settings are 1240 cyl 16 heads 63 sectors. Here is a quick
howto in getting started with Bochs.
This is a work in progress, subject to change daily. It is for my own information and if it helps or be an interest others then that would be a bonus.
Changes
21 May 2008:
I updated my Bochs image with the UNI os2ldr and os2krnl from the eCS RC4. These are not the latest but I can trace from boot through os2ldr. The file is 1.6 meg and unzips to 630 Meg and can be downloaded here:
newdrive.zip.
Note!!! download
DFSee iso and boot it as the CDROM to set the hard drive image active if it will not boot.
Hardware and BIOS Initialization
On system reset, the BIOS is given control by the CPU. After performing tests and system initialisation, the BIOS starts the system boot operation; this all takes place in real mode, generally using 16 bit code, although some 32 bit instructions may be used. The actual sequence of operation depends on the BIOS options selected, but in most cases the BIOS will attempt to boot from the first diskette drive; if this fails, it will attempt to boot from the first hard drive. In both cases, the basic operation is the same, although the following is primarily about booting from a hard drive.
The boot operation consists of reading the first sector (cylinder 0, head 0, sector 1) from the boot device, and placing it into memory starting at address 0000:7C00H (segment 0, offset 7C00). Control is then transferred to address 0000:7C00H, i.e. with CS (the code segment register) set to 0000H, and IP (the instruction pointer) set to 7C00H. Note that this is functionally different to having CS set to 07C0H, and IP set to 0000H!
- Move itself in memory, to vacate the area it occupies in order to make way for the boot sector for the partition being booted. Conventionally, it is moved to 0000:7E00H.
- Check for Boot Manager partition on first and second drive (if installed)
- Validate the partition table (checking for exactly one active partition, and for format errors).
- Read the boot sector (first sector) from the active partition, into memory at 0000:7C00H; this mimics the effect if the disk were not partitioned at all (as would be the case for a diskette).
- Transfer control to 0000:7C00H.
Progress ToDate
What have I found out so far? Quite a bit that I find interesting. I will describe the information in the phases I disassembled.
Phase 1 -- The MBR
In brief, control is passed from BIOS to the loaded MBR code at 07C0:0000. The code relocates itself to 07E0:0000, checks for a Boot Manager partition, and checks for a bootable partition. Once a bootable partition is found, the partition boot record or more correctly the BIOS parameter block (BPB) is loaded at 07C0:0000 and control is passed to it at 07C0:0000.
Remember, as I understand the MBR is created by the LVM utility (ex: LVM /NEWMBR). At this point the system is using INT13 calls to interface with the drive. The errors that can be encountered during this phase are:
- SYS01462
- SYS01463
- SYS01464
More detailed information can be found here:
Phase 2 -- The Partition Boot Block
This code uses INT 12 to, in general, find the top of low memory. Next, the result (approx 639) has 54h subtracted, AND result with FFF0h, and then shifted left 6 bits. This will be the load segment for the next code file (ie calculated load segment). The Bochs drive returns 639 from the INT12 call, so the load segment is 8800h.
All disk access during this phase uses INT13 calls to interface with the drive. After loading the next module a far return to (calculated load segment):199C is performed. This code is placed in the partition when the sysinstx.com file is run against it. So, the sysinstx.com executable writes the partition sector/micro-FSD and os2boot.
The errors that can be encountered during this phase are:
- an error when performing the next module load (INT13 Ext) which results in an emission of DAP information, - SYS2027 - message, and the system hangs. Getting this error is an indication of a failed INT13 load from the procedure readdrive which is also used in Phase 3.
- 'Invalid code for JFS' (followed by address code) which is emitted after the next module is loaded and a check for the signature 1961h at (calculated load segment):0200 fails. For normal operation I assume this error would be an indication that os2boot could not be loaded and possibly running sysinstx.com against the partition could correct it.
The module loaded in Phase 2 contains code to continue the boot process and the micro-FSD. Using the Bochs drive image, 20h sectors are loaded at 8800:0000 and the entry point is 8800:199C.
More detailed information can be found here:
Phase 3 -- The Partition Boot Block Plus Extra (micro-FSD).
After a bit of playing, I found that the load in Phase 2 does indeed reload the Partition Boot Block and an additional 31 sectors at 0x88000. Looking at the code and stepping through execution with Bochs, I have confirmed this to be correct.
I am starting to see the structure of the Phase 3 load and it does not seem as documented. I believe this module loads os2boot and it only contains the mini-file system. It next loads os2ldr, sets up the required structures and then jumps into os2ldr.
I'm going to post my notes to the blog, link at top of the page.
There are no comments on this page. [Add comment]