Does a BIOS have any special function that another program could not do?

Question

I just want to ask, when I was searching informations about BIOS, I found mostly outdated articles, so I just have a few simple questions about how it works today.

If I am correct, main BIOS purpose is to load information from HDD to the CPU (some OS mainly). Later, they added small routines you could call using int instruction which made simple some tasks in PC, like accesing HDD, or accesing VGA and so.

But if I am still correct, all this work can be done manually by every other program that has ring 0 mode. I mean, BIOS has no special function every other program could not have, am I right?

I know in DOS days BIOS routines were heavilly used. But nowadays, are they? I mean, does OS these days even use BIOS routines? When there are drivers for everything?

But BIOS still gets updated a lot, with many bug fixes, so I wonder what exactly is role of BIOS nowadays.

As of example, I am thinking of changing FSB frequency. You can do it thru BIOS, but you had to have other way to do it right? Since BIOS is only program.

Only thing I think you might need BIOS for is compatibility layer between OS and Specific hardware, like chipset, but still, if you knew the exact way to get to hdd (which ports and which data to send to them) you could to this without BIOS is it right? Thanks.

Answer 1

The 'BIOS' bit of 'The BIOS' is indeed the compatibility layer between hardware and the OS. Yes, you could directly drive the hardware BUT you'd need to write driver code for every variant of motherboard design in order for your app to work on every machine. In the very dim and distant past when Lotus 123 was a DOS app, the very first few versions drove the parallel printer port directly to speed up printing performance, which was all well and good if you had a true IBM PC or a very good clone, but on some PCs, 123 would not print because the parallel port's electronics were slightly different from the IBM design.

The BIOS hardware routines and interrupt mechanisms also help arbitrate between multiple apps trying to use the same hardware or read the same registers simultaneously and so the BIOS prevents anarchy - aka crashes between apps competing for access to low-level hardware.

The other two parts of 'the BIOS' are the power on self test (POST) routines and the 'CMOS setup program' for the computer.

Moves have been afoot to replace the BIOS design for some time - not least because its functionality as a hardware compatibility layer comes at a performance price. More and more computers are now being built with an alternative way of doing things called the Extensible Firmware Interface (EFI - now morphed into the Unified EFI or UEFI) - Apple have used EFI for some time and so have some high-end desktop and server machines. If you want to know more, have a look at this Wikipedia article. and here's a recent news piece.

Answer 2

You're misunderstanding one VERY important thing. BIOS is not software, it's firmware. It is the part which standardizes functionality at HW level. It is what loads all other "programs".

Main problem with allowing OS to directly drive hardware are improvements. For example it has been proven that traditional x86 processors are dead end long time ago. Modern "x86" processors are not x86 internally. Instead they too have a firmware (in this case called microcode) so that they appear to be x86 processors. Use of firmware is a level of encapsulation. Also modern x86 processors need to support instructions which were needed because of quirks present in 8086 and 268 systems even if they aren't used much today.

Basically, OS itself is not concerned how hardware works. It sees what BIOS shows it, which may or may not be correct on hardware level. This creates separation of responsibilities among people engaged in computer manufacture and design and allows for every organization to concern itself with parts closest to it. Most programmers don't know how a processor or a motherboard work on low level and they don't need to know because they program to a specified interface. On the other hand chipset designers do know how a motherboard works, so they also program BIOS to a specified interface. Manufacturers of motherboards themselves don't actually make motherboards from scratch. They take completed components and integrate them into a single system and they modify motherboard's BIOS a bit to work with components used. There too firmware is present because BIOS communicates with firmware of network chip or with firmware of audio chip and so on.

The BIOS updates you see often aren't updates of some core functionality. Instead today motherboard makers need to launch their products as fast as possible, so they try to make their BIOS modifications as quickly as possible which often leads to bugs. Sometimes BIOS updates are there to fix firmware of some other device. For example Intel makes available updates for microcode of its processors. If a major bug is identified in a processor, Intel will send those updates to manufacturers of motherboards which use affected processors which will make BIOS updates which will update processors microcode (microcode is read-only, so this needs to be done at each boot).

As for changing FSB frequency and similar, you always do it through BIOS. It's just that some BIOSes expose to programs components which are in charge of FSB so that they can be modified by a program. Still, those programs are specialized because they need to know with what they are working with.

Another point are hardware manufacturers. Hardware itself needs to know where to look for programs. On simple microcontroller systems (they are just like computers from 30 years ago in their capabilities) you have program starting point. Microcontroller always reads a single memory address where data on where program is starting is stored. BIOS does that for PCs. Imagine how complicated it would be if processor would access data directly on HDD. It would need to know how everything from itself through chipset, HDD controller, and HDD itself works and where on HDD is operating system stored.

After reading your question several times, I think that the main problem with your vision of BIOS and its place is how closely is operating system connected with hardware on modern PC. It has been decided that on PCs OS isn't going to be that closely connected to hardware. Over time that decision has proved itself to be good. Take a look at coreboot (Wikipedia article) project. They are implementing whole GNU/Linux operating system in computer's BIOS chip. as you can see, they have many problems related to available information about specific motherboards, but they have their advantages. Their system can boot in just several seconds. Another interesting computer is Acorn. Their computers had whole OS places info a single chip. There is Apple too. Their OS is not so tied to hardware and it's possible to make hackintosh, but relation is till closer that it is on PC.

In the end, I think that the main reason for existence of BIOS today is openness of PC platform. It is very easy to make hardware for PCs and one of the main reasons for that is that there isn't a single company which controls PC specification. If BIOS (or its newer replacements) is to be eliminated, you'd need someone to be there to make sure that OS developers and hardware designers are synchronized and that would be extremely complicated.

Answer 3

A long time ago, computers didn't have bootstrap ROM. One had a direct interface to modifying RAM, and could halt the CPU, change RAM, and then restart the CPU. So, when you restarted the system, you had to make sure the CPU was halted, enter your bootstrap code that would load a second stage bootloader (2bl) off of paper tape or whatnot, and then "unhalt" your CPU.

ROM saves the day here, obviously. When you power on an x86 CPU-based system, it begins executing at address FFFF:FFF0. That's a hardwired feature of the x86 CPU. ROM has to reside at that address, and indeed the very upper part of the BIOS does (usually starting at E000:0000).

The term BIOS is a holdover from the old CP/M operating system. The structure of CP/M was the ROM BIOS at the lowest layer, the BDOS (Basic Disk Operating System) in the middle, and the CCP (Console Command Processor) in front of the user. The BIOS had routines to perform low-level functions such as reading/writing a specific disk sector, reading a key from the keyboard, writing a character to the screen, etc. The BDOS would use BIOS functions to implement a file system, and the CCP would be the command shell using BDOS and BIOS functions. The idea was the BIOS would contain the hardware specific interface, and the BDOS and CCP could be the same on any CP/M system.

The BIOS would also hold the initial code executed by the processor, which initialize required hardware, display a splash screen, load the 2bl off the first sector off of the first disk drive and run it.

MS-DOS 1.0, pretty much being a x86 implementation of CP/M, with kludgy Unix-like features added on starting at version 2.0, was structured the same way. The IBM PC BIOS at that time also included enhancements such as video mode switching, graphics functions, and hard drive support in the original AT BIOS.

However, most DOS programs did not use BIOS functions once they started; they directly accessed hardware for performance reasons. This was especially important after 32-bit CPU's became commonplace; the BIOS only worked from the older 16-bit mode, so calling it from 32-bit mode incurred a further performance penalty.

Around the 1990 the PC architecture was beginning to be extended, and starting to include new stuff like APM, PnP, and PCI. So the BIOS was starting to take on additional functions and get bigger. PCs also were starting to use chipsets instead of discrete components. Initializing the chipset is something that needs to happen to get RAM and other components such as the PCI bus usable, so that has to be handled by the BIOS bootstrap code. For some reason many chipset vendors do not like to document how their setup processes work.

APM was handled by BIOS functions; i.e. to power the system off the operating system had to call an APM function. ACPI, APM's successor, is the big thing BIOSes do today. The ACPI BIOS is responsible for creating a bunch of tables in memory that describes many non-plug and play hardware components. A booting operating system uses this to determine how many CPUs there are, how many RAM slots the system has, whether the system is a desktop or laptop, how many batteries are installed, etc. The ACPI BIOS also must be called to power off the system, or place it into sleep, etc. There's no reason that operating system code couldn't handle ACPI calls, though.

Most of the time BIOS updates are to fix ACPI errors, since ACPI is complicated and difficult, or to introduce enhanced microcode. All modern CPU's allow microcode updates, and if a new microcode update is released the BIOS must then be updated to install that new microcode. It's possible for a normal program to update a CPU's microcode.

SMI's are also handled by the BIOS. I'm pretty sure most of the thermal and power related hardware in a PC triggers SMI's, whose routines then adjust fan/CPU speed and/or other things. Other things can trigger SMI's; check out the Wikipedia article on System Management Mode. But there's also no reason that this code couldn't be replaced with operating system code if hardware interfaces were documented.

Modern operating systems do not use the BIOS at all for hardware access, except for power events. Some bootloaders do use the BIOS character I/O to display text and disk I/O load the OS boot code.

So I hope this sheds some light on the BIOS's role, and for the most part you are absolutely right about how it works.