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
Hiya "David J. Coffin" wrote:
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.
MicroPose (MicroProse?) - do the Micro2000, which is a rather useful POST probe..... It's not cheap, but well worth it for the usefulness, it is listening address configurable, and will provide extra diagnostics like Osc check, clock check tri state logic probe, and of course all the voltages.... One thing tho.. don't ask me how to get hold of the company, I haven't dealt with them for a _long_ time, they are US based with an office here in the UK... Yours Matthew
Matthew Sullivan wrote:
MicroPose (MicroProse?) - do the Micro2000, which is a rather useful POST probe.....
It's not cheap, but well worth it for the usefulness, it is listening address configurable, and will provide extra diagnostics like Osc check, clock check tri state logic probe, and of course all the voltages....
We *could* make our own. A POST card is an ultra-simple device, It simply latches data from a specific port reserved for POST (I forget which one off-hand though) and displays it via either a bank of 8 LEDs in binary or two 7-segment LED displays in hex. There are schematics in many electronic magazines (when Microcomputer Journal was Computercraft, I believe they ran one, I think Popular Electronics also ran one a while ago). I can search through all of my old magazines to find the basic schematic. We can add extra features as we wish, for example, a PIC could be thrown on there to translate the data to a serial port (on the card, of course) or to an LCD module with extra information. It doesn't matter that the PIC is slower than the PC. We could also add extra functionality such as a simple parallel i/o port, i2c (which the PIC could handle nicely), analog switches, etc. We could set it up to display POST codes on an LCD or LED module on the front of the PC (it gets hard to read the display on a POST card if other cards are blocking it). We could even build a ROM programmer into it as an external module. This is an easy design, even with all the extra features. I have an ISA prototype card I can play with. The most expensive part would be, of course, the PCB (I paid CAN$50 for my prototype card) but if a bunch of us wanted to make some (I have many friends who would be interested in such a device, parallel ports tend to run out quickly) we could get away with some relatively cheap PCBs if we find the right place (I hear ExpressPCB is pretty cheap). If anyone's interested (we *will* need post cards, especially for debugging purposes), respond. It would also be nice to have a ROM burner on it as I'm sure we will all need one of those as well. James Oakley jfunk@roadrunner.nf.net
Hi James Oakley wrote:
Matthew Sullivan wrote:
MicroPose (MicroProse?) - do the Micro2000, which is a rather useful POST probe.....
It's not cheap, but well worth it for the usefulness, it is listening address configurable, and will provide extra diagnostics like Osc check, clock check tri state logic probe, and of course all the voltages....
We *could* make our own. A POST card is an ultra-simple device, It simply latches data from a specific port reserved for POST (I forget which one off-hand though) and displays it via either a bank of 8 LEDs in binary or two 7-segment LED displays in hex.
There are schematics in many electronic magazines (when Microcomputer Journal was Computercraft, I believe they ran one, I think Popular Electronics also ran one a while ago). I can search through all of my old magazines to find the basic schematic.
Practical Electronics - about 3-4 years ago did one as well..... The Microprose one is rather good, and my recomendation because of the book that comes with it, it's _very_ comprehensive on what you should expect to see from each BIOS, which whilst we are writing our own, it will remind us what we should be pushing to the port on boot, and of course what we should testing on boot...
We can add extra features as we wish, for example, a PIC could be thrown on there to translate the data to a serial port (on the card, of course) or to an LCD module with extra information. It doesn't matter that the PIC is slower than the PC.
We could also add extra functionality such as a simple parallel i/o port, i2c (which the PIC could handle nicely), analog switches, etc. We could set it up to display POST codes on an LCD or LED module on the front of the PC (it gets hard to read the display on a POST card if other cards are blocking it).
We could even build a ROM programmer into it as an external module.
This is an easy design, even with all the extra features. I have an ISA prototype card I can play with.
The most expensive part would be, of course, the PCB (I paid CAN$50 for my prototype card) but if a bunch of us wanted to make some (I have many friends who would be interested in such a device, parallel ports tend to run out quickly) we could get away with some relatively cheap PCBs if we find the right place (I hear ExpressPCB is pretty cheap).
I would say that we would probably only want a 'diagnostic/dev' card rather than one with lots of extras... However a useful feature might be a dual BIOS socket with a switch circuit of some sort (digital electronics design is not a strong point for me) just to save yanking the 'good' BIOS for replacement with the 'corrupt' BIOS to re-programme it.
If anyone's interested (we *will* need post cards, especially for debugging purposes), respond. It would also be nice to have a ROM burner on it as I'm sure we will all need one of those as well.
> 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.) * initialize VGA-BIOS (call it), but this has to be done in Realmode, right? a little problem.... > * 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. > 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. i can get one for about 150DM (~100$) It's from the german electronic-service "ELV" perhaps a good idea. > 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. i know these boards. (Intel Endeavor and so on.) :( Ciao, Stephan [SpaceNet-Systems]
On Sat, 13 Mar 1999, [iso-8859-1] Stephan M�ller wrote:
> > 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.)
> * initialize VGA-BIOS (call it), but this has to be done in Realmode, right?
> a little problem....
Yes, that's a real problem. You could switch to Real
Mode, execute the ROM, and switch back. Or you could run
it in Virtual 8086 mode, which would provide more control.
Or we could just handle the device ourselves, like Linux
does.
I don't like adapter ROMs. They are, in effect, device
drivers written for an obsolete CPU architecture (the 8086)
and an antique operating system (DOS). And they are always
closed-source, usually bearing the message "DECOMPILATION
OR DISASSEMBLY PROHIBITED".
There are really two problems we need to solve: VGA
and SCSI. The OS can take care of everything else.
All VGA cards support 80x25 text mode in hardware, and
that is sufficient for our needs. We don't need any of the
INT 10h services, so the only question left is "How do I
turn on this card?".
For SCSI, we'll offer stripped-down replicas of the
Linux SCSI drivers. If your SCSI card is not yet supported
by OpenBIOS, you'll need to load the OS kernel off a floppy
or IDE drive.
On another topic, should we all work on different
motherboards, or focus our efforts on one? My choice would
be one of those new 100MHz Super-7 boards with a VIA Apollo
chipset, because it's the fastest board you can get with
"No Intel Inside".
Dave Coffin 3/14/99
--
David Coffin Evening: 781-397-9932
967 Salem Street Daytime: 978-686-6468x341
Malden, MA 02148-4515 E-mail: dcoffin@shore.net
* initialize VGA-BIOS (call it), but this has to be done in Realmode, right? a little problem.... Yes, that's a real problem. You could switch to Real Mode, execute the ROM, and switch back. Or you could run it in Virtual 8086 mode, which would provide more control. Or we could just handle the device ourselves, like Linux does. Virtual mode. Hm. What's if the VGA-rom wants to write to a port we didn't accept? This could cause in no display. :) The best Idea is to support Standard-VGA-Cards. Nearly every card is compatible with it (look at the Linux-kernel, i think it's got it's own VGA-driver, right?)
I don't like adapter ROMs. They are, in effect, device drivers written for an obsolete CPU architecture (the 8086) and an antique operating system (DOS). And they are always closed-source, usually bearing the message "DECOMPILATION OR DISASSEMBLY PROHIBITED".
:-)
There are really two problems we need to solve: VGA and SCSI. The OS can take care of everything else.
That's the reason why we NEED a modulary-design like the linux-kernel. a gzip-compression like the linux kernel (an analogy to the LHA-compression of Award-Bioses)
All VGA cards support 80x25 text mode in hardware, and that is sufficient for our needs. We don't need any of the INT 10h services, so the only question left is "How do I turn on this card?".
By writing the standard data onto the ports. (i hope so, i think we have to test this)
For SCSI, we'll offer stripped-down replicas of the Linux SCSI drivers. If your SCSI card is not yet supported by OpenBIOS, you'll need to load the OS kernel off a floppy or IDE drive.
Funny. :)
On another topic, should we all work on different motherboards, or focus our efforts on one? My choice would be one of those new 100MHz Super-7 boards with a VIA Apollo chipset, because it's the fastest board you can get with "No Intel Inside".
Yeah, i've got a FIC VA503+ (Via MVP3-based) Rulez! :) But my father's got a VB601 (Intel 440BX-based), of course we need drivers for this chipset, too I think we should make a list of the most popular chipsets. And, of course, a generic-driver. But the biggest problem is: If somebody decides to flash his board with the openBIOS, there is no turning back, if it isn't working he has got a problem! :) Ciao, Stephan [SpaceNet-Systems]
participants (5)
-
David J. Coffin -
James Oakley -
Matthew Sullivan -
Stephan Mueller -
Stephan Müller