Category Archives: bootldr

More output…

I finally hooked up output from the detected serial port using a DosHelp routine, but it might short lived if I can’t use it after relocation.

Guess the best part is that the IODelay matches what I see with a debug kernel on the same machine.

LDRINFO: Loader initialized and running …
Serial out: COM1 Address 3F8 BPB 0X8800:0XB
FileTable 0X8800:0X124A Bootflags: 0X1481
LDR: 0X1000 microFSD: 0X8800 miniFSD: 0X7C endldr: 0X5000
COM: 0X3F8 0X0 0X0 0X0 LPT: 0X378 0X0 0X0
OS2LDR size: 19326 GenuineIntel Type: 0X6 Model: 0X8
IODelay: 244 T0: 0 T1: -2 T2: -263 A20 gate enabled INT15-C1 not supported
bus:dev:func 0:0:0 0:1:0 0:1E:0 0:1F:0 0:1F:1 0:1F:2 0:1F:3 0:1F:5
bus:dev:func 1:0:0* 1:0:1 bus:dev:func 2:3:0*
PCI BIOS 2.16 Number Bus: 3 Status: C00 :: EISA not found
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 – 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 – 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 – 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 – 000000003fff06c0 (usable)
BIOS-e820: 000000003fff06c0 – 000000003fff66c0 (ACPI data)
BIOS-e820: 000000003fff66c0 – 000000003fffe700 (ACPI NVS)
BIOS-e820: 000000003fffe700 – 0000000040000000 (reserved)
BIOS-e820: 00000000fec00000 – 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 – 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 – 0000000100000000 (reserved)

LDRINFO: End message

DosHlp Routines

In brief, which is all I can do, the os2ldr contains some hardware dependent routines call DosHlp routines. Thanks to Pasha for pointing out that the ddk contains which lists most of these (baseinc).

The os2ldr contains a table of offsets that is passed to the kernel. The following is a structure I put together from this information and what I saw from a disassembled os2ldr (SMP v104a). The unknowns are not listed in the

typedef struct _DOSHLPFUNCTIONS {
uint16_t TableVersion;
uint32_t DosHlpInit;
uint32_t DosHlpReboot;
uint32_t DosHlpNMI;
uint32_t DosHlpSizeMem;
uint32_t DosHlpConfig;
uint32_t DosHlpBaseDDList;
uint32_t DosHlpGetDriveParms;
uint32_t DosHlpInitSystemDump;
uint32_t DosHlpSystemDump;
uint32_t DosHlpReadSectors;
uint32_t DosHlpSerInit;
uint32_t DosHlpSetBaudRate;
uint32_t DosHlpSerIn;
uint32_t DosHlpSerOut;
uint32_t DosHlpToneOn;
uint32_t DosHlpToneOff;
uint32_t DosHlpGetMask;
uint32_t DosHlpSetMask;
uint32_t DosHlpSetRealMask;
uint32_t DosHlpSetProtMask;
uint32_t DosHlpSetDosEnv;
uint32_t DosHlpCallInt10;
uint32_t DosHlpProtGetMessage;
uint32_t DosHlpRealGetMessage;
uint32_t DosHlpRegisterTmrDD;
uint32_t DosHlpTmr16QueryTime;
uint32_t DosHlpEnableWatchdogNMI;
uint32_t DosHlpDisableWatchdogNMI;
uint32_t DosHlpInstallIRET;
uint32_t DosHlpDiscard;
uint32_t DosHlpInitInterrupts;
uint32_t DosHlpSetIRQMask;
uint32_t DosHlpSendEOI;
uint32_t DosHlpTmr32QueryTime;
uint32_t DosHlpTmrSetRollover;
uint32_t DosHlpInitNPX;
uint32_t DosHlpClrBusyNPX;
uint32_t DosHlpAckIntNPX;
uint32_t DosHlpWaitNPX;
uint32_t DosHlpValidNPXSwitch;
uint32_t DosHlpVNPXReset;
uint32_t DosHlpVNPXClrBusy;
uint32_t DosHlpWhyNMI;
uint32_t DosHlpAckNMI;
uint32_t DosHlpResetWatchdogNMI;
uint32_t DosHlpDisableCache;
uint32_t DosHlpFindParity;
uint32_t DosHlpEnableCache;
uint32_t DosHlpGetErrorLogPtr;
uint32_t DosHlpWriteErrorLog;
uint32_t DosHlpReadErrorLog;
uint32_t DosHlpResetParity;
uint32_t Unknown1;
uint32_t Unknown2;
uint32_t Unknown3;
uint32_t Unknown4;
uint32_t Unknown5;
uint32_t Unknown6;
uint32_t Unknown7;
uint32_t Unknown8;
uint32_t Unknown9;
uint32_t Unknown10;
uint32_t Unknown11;


I have joined the osFree Project at Sourceforge and will keep a mirror of my loader project there.

In the process of hooking in the freeLdr micro-FSD calls, I found a real pain in the ass with BootableJFS. Each call to open clears the screen and displays their copyright message. This messes up any messages anyone else wants to display…

The fix? Well in the newest BootableJFS (as of 2008) Pasha has a turn off. At the JFS uFSD segment and offset 0x1944 a check is made for the byte value 0x0F. If this is set to anything else the message is not displayed.

Entry into os2ldr

Using Bochs I have the entry values into os2ldr when booted with BootJFS. One important note is that any of the filetable structure len fields will depend on the module version. Also, the 0x8800 segment might vary with machine types in the real world. It is calculated:

  1. uses INT 12 to find the top of low memory in continuous 1k blocks
  2. subtract 0x54
  3. AND with 0xFFF0
  4. Shift left 6

DX == 0x1480 (00010100 10000000)
DH boot mode flags == mini-FSD is present, micro-FSD is present
DL drive number for the boot disk == 0x80

DS:SI is a pointer to the BOOT Media’s BPB 8800:000B (0x8800B)

ES:DI pointer to a filetable structure 8800:124A (0x8924A), filetable structure has the following format:

; module locations

8924A ft_cfiles dw 3
8924C ft_ldrseg dw 0x1000
8924E ft_ldrlen dd 0x0000AE00
89252 ft_museg dw 0x8800
89254 ft_mulen dd 0x00005000
89258 ft_mfsseg dw 0x7C00
8925A ft_mfslen dd 0x0000EAE9
8925E ft_ripseg dw 0
89260 ft_riplen dd 0

; microFSD vector table

89264 ft_muOpen_OFF dw 0x1A9C
89266 ft_muOpen_SEG dw 0x8800
89268 ft_muRead_OFF dw 0x1BD4
8926A ft_muRead_SEG dw 0x8800
8926C ft_muClose_OFF dw 0x1DAE
8926E ft_muClose_SEG dw 0x8800
89270 ft_muTerminate_OFF dw 0x1DD4
89272 ft_muTerminate_SEG dw 0x8800

ah… BootJFS and the process

I’m going to plagiarize from and modify the text to fit my adventures with BootJFS.

At the end of POST procedure the ROM BIOS initializes devices and gives control to int 19h interrupt routine, which loads 1st sector of the 1st boot device (a floopy, HDD or another). If the device was the HDD, then the Master boot record (MBR) is loaded from the 1st sector. The ROM BIOS loads it at address 07C0:0000. The MBR has a Non-System Bootstrap (NSB) routine in it, and the Partition Table (PT). The NSB code relocates MBR to 07E0:0000, jumps to 07E0:0020 and checks for a Boot Manager partition, and checks for a bootable partition on the first or second disk if present. Next the bootsector of boot HDD partition is loaded at 07C0:0000.

One of the interesting things that happens is the following:

1. Find the top continuous low memory (conventional 640k), number of 1K blocks. On my Bochs drive 639 is returned.

2. Calculate a load segment. The result of #1 – 54h, AND result with FFF0h, and then shifted left 6 bits. This will be the load segment and with the Bochs drive equates to 8800.

3. The bootsector of boot HDD plus an additional 31 sectors are loaded at the address (segment) calculated in #2, approximately 16K.

4. A jump to the segment from #2 offset 199Ch is made.

Now things have and continue to divert from IBM documentation. The code loaded in #3 contains MicroFSD. It loads os2boot and os2ldr using MicroFSD functions, which look like C code. Finally, the structure and registers are setup for entry into os2ldr.

One of my issues is that the structure I am finding does not seem to match documentation:

124A ft_cfiles dw 0
124C ft_ldrseg dw 0
124E ft_ldrlen dd 0
1252 ft_museg dw 0
1254 ft_mulen dd 0
1258 ft_mfsseg dw 0
125A ft_mfslen dd 0
125E ft_ripseg dw 0
1260 ft_riplen dw 0
1262 db 0
1263 db 0

; microFSD vector table
12641264 ft_muOpen_OFF dw 0
1266 ft_muOpen_SEG dw 0
1268 ft_muRead_OFF dw 0
126A ft_muRead_SEG dw 0
126C ft_muClose_OFF dw 0
126E ft_muClose_SEG dw 0
1270 ft_muTerminate_OFF dw 0
1272 ft_muTerminate_SEG dw 0

Notice 1262h and 1263h, I do not know what they are used for…