site logo  BootableJFS

HomePage | Categories |* BLOG *| RecentChanges | RecentlyCommented | Login/Register

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!

The previous from Bob Eager, Tavi Systems page The OS/2 boot sequence.


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:


More detailed information can be found here:

LVM MBR Disassembled

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:


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:

Bootable JFS Bootsector Code (BPB)

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.

Bootable JFS micro-FSD

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]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki 1.1.6.7
Page was generated in 0.4483 seconds