New subject: POST Probes -> Was -> Re: Here's a plan

9 Mar 1999


      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