Proposed OpenBIOS Boot Specification
Pre-boot:
OpenBIOS performs the following steps:
* Switch the CPU to 32-bit protected mode. * Detect the DRAM and set chipset registers accordingly. * Enable devices on the Super I/O (floppy, COM ports, etc.) * Scan the PCI bus and allocate requested resources. * Look for known boot devices: floppy, IDE, ATAPI, various SCSI cards, and anything else that might be bootable. * Select one of these devices. Read the first sector into memory and jump to it.
Some sort of setup utility will be added later, probably similar to Sun's command-line boot PROMs. For now, all op- tions will be set at compile time.
Boot Sector:
The boot sector begins execution with the CPU in 32-bit protected mode, privilege level zero, interrupts disabled, A20 gate on. The CS, DS, ES, and SS selectors all have base address 0, limit 0xFFFFFFFF. All except CS are read/write.
EBX and EIP contain the base address of the boot sector. Addresses below this belong to OpenBIOS. Do not modify them as long as you need to use the OpenBIOS services.
ESP points to the top of DRAM, and your initial stack.
Services:
The service routines are accessed by loading AX with the desired service and calling the Service Entry Point, at 0x000FFFE0.
* Read Sectors from Boot Device *
AX = 0x0000 EDX = Starting sector number ECX = Sector count ESI = Address to store the first sector read
Sectors are counted in a linear fashion, starting from zero. Since each sector is 512 bytes, the OS kernel must reside within the first two terabytes of the boot device.
OpenBIOS does not write to block devices. That must be done from the OS kernel.
* Read Data from Console Device *
AX = 0x0100 ECX = Max number of bytes to read ESI = Address to store incoming bytes
* Write Data to Console Device *
AX = 0x0101 ECX = Number of bytes to write ESI = Address of data to write
The "console device" may be either a monitor and keyboard, or a serial port. For now, consider it a dumb ASCII terminal, although more capabilities might be added later.
What other services do we need?
Special addresses:
The OpenBIOS ROM image starts at 0xE0000 or 0xF0000 depen- ding on the hardware. It might be copied into shadow RAM. The following addresses are defined; all others are reserved:
0x000FFF80 The BIOS ID string, up to 96 bytes long. The first eight bytes must be "OpenBIOS", so that LILO will know which boot loader to install. The string also contains the version number, motherboard name, and a list of features supported by this BIOS. 0x000FFFE0 Service Entry Point 0x000FFFF0 CPU Reset Vector
Basic Techniques:
For the last 2.5 years, I've worked at Unicore Software, building custom versions of Award BIOS and (the nearly defunct) MR BIOS. Here are the basics:
You need one computer for building BIOSes and another for testing them. It's nice if they have separate monitors and keyboards.
I use a $500 ROM emulator, connected to my workstation by a serial cable. A cheaper alternative would be to insert a ZIF socket between the ROM chip and the motherboard. Boot up with the "good chip", swap in the "test chip" (after the good chip has copied itself to shadow RAM), flash your code onto the test chip, and reboot.
If your test motherboard has one of those wafer-thin PSOP flash chips with microscopic pins, forget it. Intel loves to make flash-proof motherboards, and then code the BIOS to reject any non-Intel CPU.
You will need some sort of debugging output long before you figure out how to turn on the the video card.
I use three ISA postcards displaying I/O writes to ports 80h, 84h, and 300h. Unicore has stopped selling these cards, so these few leftovers are very precious to me. They bear the inscription "ORCHID UNIO993 REV B". If they can't be bought, I'll write up a design spec and post it.
One possibility I haven't explored is sending debug data out the serial port.
Overall Strategy:
Buy one of the new "Super 7" motherboards with the VIA Apollo chipset and a socketed flash chip. For starters, hard- code the Super I/O and PCI settings to match the original BIOS. Write code to read (not write) a floppy disk, and write a sim- ple boot sector to test it. Then do the same for IDE. In a few weeks, depending on your programming skill, you'll have a bootable (albeit highly un-portable) BIOS.
Linux should still work fine, with a few changes to the boot loader. Don't tell me about booting DOS & Windows--I work with 16-bit BIOS code every day and it is a *nightmare*. Linux didn't get where it is today by cloning Windows, and we won't get anywhere by imitating Award or Phoenix.
Dave Coffin 3/9/99 -- David Coffin Evening: 781-397-9932 967 Salem Street Daytime: 978-686-6468x341 Malden, MA 02148-4515 E-mail: dcoffin@shore.net