Hi,
ComputerPsi wrote:On POST, correct me if I am wrong, but it seems that all BIOSs test the keyboard, and sets the PIT.
So, when first starting your OS, is there any need at all to set any default configurations for the keyboard, or any need to test the keyboard in any way?
That depends...
First, there's seperate things involved - there's the "PS/2 controller" (part of the chipset) and then there's the "PS/2 devices" that are plugged into it (keyboard, mouse, etc). A PS/2 device talks to the controller using serial communication, and the controller is mostly just a chip that handles 2 "special purpose" serial ports.
There aren't any limitations in hardware that determine which devices must be connected to which PS/2 ports (you can have the mouse and keyboard around the other way, or have 2 keyboards and no mouse, or 2 mouses and no keyboard). Even better, an OS can easily auto-detect which type of device (if any) are connected to each PS/2 port. However...
For the first PS/2 port the controller has the ability to convert from scan code set 2 (what the keyboard sends) into scan code set 1 (what old software expects to see). This scan code translation is enabled by default, so if you plug a mouse into the first PS/2 port it trashes the data, and if you've got 2 identical keyboards (one plugged into each PS/2 port) you'll get different scan codes from them. By re-initializing part of the PS/2 controller you can disable this translation. However...
Some PS/2 controllers (mostly 80486 chipsets) don't support both PS/2 ports. Some of them ignore any attempt to talk to the (missing) second PS/2 port and some of them redirect data intended for the (missing) second PS/2 port to the first PS/2 port (so it can look like there's 2 keyboards when there isn't). To seamlessly support "anything in any PS/2 port with full auto-detection" you need to mess with the PS/2 controller's configuration to determine if it supports both PS/2 ports, and if you're doing this (and disabling scan code translation on the first port) then you've got nothing to lose by fully reconfiguring the controller while you're doing it.
You might also want to design your OS so that it can be used in embedded systems, where the OS is stored in ROM and where the "boot loader" is some custom ROM code designed specifically for the embedded system. In this case, if the OS assumes that nothing has been initialized and does it's own initialization, then it makes life easier for people writing/porting a "ROM boot loader" for a new embedded system (e.g. they can ignore the PS/2 controller if they know the OS will initialize it).
Then there's the PS/2 devices. You can't assume the BIOS will initialize anything except for one keyboard (and only if it's plugged into the first PS/2 port). Also, it's possible to support "hot plug PS/2" where the OS detects if a device is unplugged or plugged in while the OS is running (Linux does). In addition some people (me) use KVM switches to have several computers connected to the same keyboard, video and mouse. Older KVM switches are just mechanical switches - when the user switches from one computer to another the keyboard, video and mouse are disconnected from one computer and reconnected to another (it's just like unplugging them and plugging them into another computer). One of my KVM switches are like this, and I disable "halt on keyboard error" in the BIOS so that I can boot one computer while I'm using another computer (otherwise the BIOS complains when the keyboard isn't connected and won't boot).
ComputerPsi wrote:Likewise, for the PIT, doesn't BIOS set the timer to it's default state? Pulsing every 65,536 clock ticks?
It does, but who wants a slow (18.2 Hz) timer IRQ? Most OSs that use the PIT reprogram it to something faster (e.g. 1000 Hz or an IRQ every 1 ms).
ComputerPsi wrote:It just seems a complete waste to add these checks and settings if BIOS is guaranteed to do most of the stuff for you.
Anybody know anything on this subject? You may include some extra functions for diagnostics - but it would be rare for a device to fail your diagnostics test, and not fail the BIOS's tests. (In fact, I have never heard of such a thing).
In fact, one of the reasons why the BIOS's functions are noted to be so slow is because BIOS does so many checks making sure that everything is nice and workable.
The BIOS is slow for many reasons. RAM testing and waiting for hard disks to reach their operating speed accounts for most of the time. Part of the problem is "sequential programming" - for example, the BIOS could do RAM testing and initialize other devices while it waits for hard disks to become ready, but normally don't (they just waste CPU cycles instead). Another part of the problem is that BIOS code is tricky - backward compatability concerns, a mixture 16-bit real mode code and 32-bit code, not enough space in ROM to optimize properly, etc. Also, ROM chips aren't as fast as RAM and most of the POST testing, etc is done from ROM.
ComputerPsi wrote:What devices actually need to be tested, or have their defaults set? I am not talking about, for example, setting the serial port to some specific configuration to talk with the mouse.. I mean testing a device that is not tested by BIOS. As it seems many OSs blindly include all of these tests, "just in case"...
The BIOS should initialize the chipset (including hyper-transport links), the RAM, the ISA DMA controller, the PIC chips, the PS/2 controller, the PIT, the RTC/CMOS, the first floppy controller (but not other floppy controllers if there's more than one), the first 2 hard disk controllers (but possibly not other hard disk controllers if there's more than 2).
The BIOS should also do PCI bus enumeration, assign resources to PCI devices and configure PCI bridges, etc; and (if ISA is supported and the BIOS isn't too old) also use ISA Plug & Play to assign resources to ISA devices that support ISA Plug & Play.
The first video card will initialize itself from the card's ROM (but additional video cards won't). The SCSI controller (if present) will also initialize itself from it's ROM.
Note: Some servers support "hot-plug PCI" and some laptops have docking stations. Devices that are not present when the computer boots won't be initialized by the BIOS.
ComputerPsi wrote:As an example, there are about 5 or so different ways you can test the keyboard to make sure it works. You can make it do a self test, you can check the serial connection, you could reset it, you could send an echo command, and some other stuff.. All together, if BIOS already sufficiently tested the thing, any additional tests take up time and space.
Some strange questions...
If a device driver crashes and leaves it's device in some messed up state, will your OS be capable of replacing/restarting the device driver? If a device becomes faulty while the OS is running (e.g. someone spills coffee on the keyboard) will the OS detect the hardware fault, automatically send an email to the network administrator or maintenance department and continue running (possibly while the faulty device is replaced)? If a web server runs 24 hours a day for 5 years and is never turned off, how useful is the BIOS's Power On Self Test for detecting hardware failures? If a device becomes faulty when it reaches a certain temperature and the computer is turned off at 5:30 in the afternoon and turned on at 9:00 in the morning, will the BIOS detect the fault? If the motherboard/BIOS is a cheap piece of crap and the user disabled as many tests as they could to get it to boot faster, can the OS be sure that the BIOS tested anything properly?
Cheers,
Brendan
