• Category Archives OS Dev
  • Booting and System Configuration

    When booting a PC the kernel needs to know what devices the system has installed and the settings the system is using. This is available through Multiboot, a single structure that defines a memory map, the boot partition, the video mode and pointers to any loaded modules. This structure is simple and functional but is not extensible. A second version of Multiboot is available using a table of tags and is much easier to expand upon. Both of these versions provide the basic settings to have a kernel detect the hardware.

    I’ve defined another structure I plan to use called the System Configuration Table (SCFG). The table is an array of blocks that define the basic system with CPU type, a memory map and the video system. What it also offers is the ability to be extended easily by proposing new blocks for the specification to include or through private data blocks that may define custom hardware or software installed.

    The System Configuration Table starts with a header that provides the total table size and a last block pointer. SCFG can be used alongside the existing Multiboot standard as the address of the table is passed to the kernel in the ESI register which is unused by the two versions of Multiboot. To check that a valid table exists first check for a ‘SCFG’ signature and then use the table head checksum. The basic structure of a block provides a block header and a block size. If a block is reserved or not handled by the kernel it can be skipped by simply using the block size to jump to the next block.

    The System Configuration Table will be used by the Inject boot loader. More information is available here: System Configuration Table, Multiboot 0.6.96 & Multiboot 1.6



  • Pm86 – 16 bit code on a 32/64 bit host

    Well I had the idea for this as far back as 2011, using 16 bit protected mode segments to run old code in a 32/64 bit environment. I’ve already worked on a vm86 monitor and have used this to set video modes with BIOS functions, but with long mode vm86 support was dropped.

    My first attempt used a protected stack so that I could change any push or pop of the segment registers but this meant I had to emulate every stack instruction and I missed some instructions like ‘mov reg16, seg’ which gave some bad addresses when putting it back into a segment register. I started using the debug exception and trap every instruction before it ran. This works perfectly and in much the same way as a regular vm86 monitor would. I’ve tried to trap every instruction that is protected from user code and on anything that uses segment registers including segment override prefixes.

    Pm86 uses 6 LDT entries but these could just as easily reside in the GDT. Each segment register has it’s own entry and if a segment is changed then the base address for the LDT entry is changed. All the segments are 16 bit default with a 64KB limit. The monitor checks for a protected/segment opcode and if it’s not one of these returns to user code to let the CPU run the instruction. Any protected/segment instruction is emulated and the segment bases are adjusted if needed.

    The trickiest opcode was the CS override for a write instruction. CS can have a read/execute segment but not write so on all CS overrides I save the DS/ES and SS base addresses. Then I set these segments to equal the CS base address and increment the IP. This turns the instruction into a normal operation to use it’s default segment and the CPU can handle it like normal. On the next trap the DS/ES and SS segments are restored and the next instruction is run through the monitor like normal.

    Pm86 allows opcode and address size prefixes to run normally but these instructions can trigger a general protection fault if they operate on a protected register.

    A 10MB hdd image file can be found here: boot32.img.0.0.1.zip

    and the source code here: boot32.0.0.1.zip



  • Project: Steel Cap Boot

    Steel Cap Boot (scboot) is a combined MBR/Boot Sector for both hard drives or floppy disks. It loads a second stage boot loader up to 32KB at any valid 80×86 seg:off address below 1MB. Scboot supports the BPB data area for FAT12, FAT16, FAT32 & NTFS. The Partition Table data works with both traditional CHS, 32bit LBA and using this recommendation scboot also supports 48 bit LBA partition table entries.

    To use it correctly some basic values must be set in the BPB area. These are the sector size, the block sector count (cluster size), the track sector count, the head count and the volume sector count. The first sector loaded by scboot is checked for the boot signature 0xaa55 at seg:0x01fe. The load address, load size and load sector values are at the fixed address 0×0198 and can be changed for use with different boot loaders.

    If scboot is used as a Bootsector the value for load sector must also be set. The default values load the first sector of a 32KB boot loader at 0×0000:1000.

    When scboot is used as a MBR or if the load sector is set to 0, scboot searches the partition table for the first active partition entry, checks for 48bit LBA data and then loads the boot sector for that partition at 0×0000:7c00.

    Steel Cap boot is released as public domain software.

    download: scboot