Printable View
Oops, I had in my mind all hardware was checked. How about some examples of what would not be checked by BIOS as it is checking the Computer out.
Hongman and the rest of you. Let me be the first to tell if not already done - the more you know the more you know you don't know. Not counting the changes in the computer industry, there is alot already on the table that I venture not any one person knows. Whew!! :D :D
Quote:
Originally posted by hongman
And that area of memory - the first 64KB... is it KiloBytes of just Bytes?
The significance of the first 64KB of conventional memory doesn't relate directly to the BIOS chip size.Quote:
Originally posted by 104456
KiloBytes but modern bios chips can be in the 2MB range.
Just the first 64K is being checked at that point in the POST for this reason:
The next few steps are going to load some critical data into the lowest addresses in memory, starting with the Interrupt Vector Table, so this memory must be verified first. Like everything, memory checking on the original PC was slow, so the boot block code, which is little changed since the original design, doesn't want to waste time checking things that will never actually need to be checked if a prior error is found and the BIOS halts the system.
An IBM compatable only needs 64K of RAM present to attempt to boot (but would need an early DOS version, CP/M or ROM BASIC to actually do so... ), so the POST does the minimum:
13/Check low address line
14/Check low 64KB RAM
to check the minimum amount of memory the system could have before making the first use of it:
16/Load INT vector table and
19/Load the BDA into conventional memory
The BDA (Bios Data Area) then contains the information held in the CMOS memory, such as the drive specifications and amount of conventional memory present, plus any further information the BIOS has obtained from other devices, and reading this information from here is one way applications can get system parameters. If I recall correctly, the BIOS then reads from here itself to do further things like the complete conventional memory check (eg if you change the amount of memory recorded in the BDA and do a soft re-boot on a system that will still do such a thing, the BIOS will report the changed memory figure).
On the subject of the non-participation of the BIOS in Operating System function, and the likely disappearance of the BIOS as we know it now, in both cases this is largely related to Real Mode operation of the CPU.
The x86 compatable CPU series has to start in Real Mode (the 16 bit operating mode of the original 8086/88 CPUs), and BIOS code is therefore 16-bit Real Mode code. Modern 32-bit OSs run in 32-bit Protected Mode, so cannot utilise any BIOS functions, without switching back to Real Mode, which is not safe to do - if anything goes wrong in Real Mode, the OS may never regain control of the system. (A famous example is a genuine BSOD - the system is in Real Mode displaying a text mode screen, and if the system fails in its attempt to switch back to Protected Mode from there, the only recourse is re-boot).
With the elimination of 16-bit operation from Operating Systems, the desire is to remove Real Mode altogether, and have immediate operation in Protected Mode, 32 or 64 bit. In order for this to occur, the concept of a Real Mode BIOS will have to be replaced with something more advanced.
That's an interesting thought.Quote:
Originally posted by greengoose1
How about some examples of what would not be checked by BIOS as it is checking the Computer out.
The BIOS as a matter of course needs to be aware of everything in the potential equipment list of the class of IBM compatable that the system is, ie PC, AT etc.
It also needs to be aware of every device it can potentially boot from, so nowadays that includes FDD, ATA, SCSI, SATA, USB, ATAPI, LAN...
Also BIOS would have to confirm the status of anything it has to provide service routines for by means of the BIOS INT routines.
Also if it is a Plug'n'Play BIOS, any Plug'n'Play devices will have identified themselves and their parameters to the BIOS by means of the appropriate P'n'P routines.
I'm not entirely clear though on the exact staus of devices that have their own BIOS, they have to interact with the system BIOS to sign on, be allocated resources like adaptor addresses or IRQs if required etc, but I'm not sure how much checking the BIOS has to do with these type of devices. Obviously any that are bootable like LAN cards or RAID controllers have to have specific interaction with the system BIOS.
So I wonder what things would be completely left to their own devices (ha ha) by the BIOS?
Maybe something like a sound card?Quote:
So I wonder what things would be completely left to their own devices (ha ha) by the BIOS?
Also, how can a pc boot from USB? Where would it get the drivers from?
Highly interesting thread indeed, my wife would say geeky, but then... ;)
I have a question though. It was mentioned numerous times above, that the OS (and other) take over from the BIOS and hardly or never rely on it's instructions again.
Why then, can certain BIOS settings, like caching, FSB etc. have a positive/negative performance impact? Is there some logic in the OS that determines which settings to accept as is, and which to alter?
Because the bios will use these (during its initialization processing, before any OS, driver, etc. get's in the picture) to initialize devices (set parameters, set registers, turn something on or off). If the OS, a driver, or a utility application doesn't then later change (change again) what has been set then the device is going to operate as per its initial settings. Generally the OS or even driver will not by default override what it gets in terms of the state or settings related to a device.Quote:
Why then, can certain BIOS settings, like caching, FSB etc. have a positive/negative performance impact?
Platypus mentioned the Bios Data Area. This area (256 bytes) contains certain limited/basic info, addresses, flags and such related to some of the most "basic" system components (and the use of them). What's here by no means details all the hardware or contains all that is known or needed to be known about the hardware (even the basic components it does keep some info about in this area). There is another memory area used to hold what's called the Extended Bios Area. Things like additional information the system bios may need in its functioning as well as more (but not all) device info is placed in this EBDA area.
But in the case of both these areas, what's in them is really only used in modern systems by the bios or those things that may utilize the bios' services and functions. Adapter cards and OSes now tend to keep their own information tables where needed, so once the bios has passed control off these areas pretty much go unused and aren't needed.
And on the general subject of what the bios needs to know about in terms of euqipment, or what it needs to know about particular equipment. It does not need to know about everything, and does not need in many case to know a heck of a lot about certain hardware. Even where it does interface or exert control on devices (or are called upon to do so) it generally does it at a fairly simple and basic level. The bios code is not very extensive, quite simple and limited in sophistication. That's why more and more over the years things have been taken out of the hands (so to speak) and put in the hands instead of adapter rom bioses/firmware, the OS, etc.
And, even things like device enumeration as it relates to certain Plug and Play aspects (IRQs being one) can, and is in cases, taken out of the hands of the bios.
Again, the bios is not the lord and master of all that it once was. It doesn't need to be, and to an ever increasing extent it isn't practical for it to be. Given the way technology has and is changing it would be insanity, slow progress and be unmanageable if the bios manufacturers had to or were to alone deal with interfacing to devices, providing all their functionality, etc.
Fantastic info!!
Thinking about it, I never really realised how much goes on before the OS is loaded. :eek:
I'll certainly be lookin at my CMOS settings in a different way when I next change them!! ;)
If anyone has any more input, please post it, it all helps.
Regards
Hong
Understood DrMDJ.Quote:
Originally posted by DrMDJ
Generally the OS or even driver will not by default override what it gets in terms of the state or settings related to a device.
Wouldn't/Shoudn't this be an area to address, i.e. wouldnt' the manufacturer of OS, vidcard, ram etc. have a routine verifying these settings and either change or advise the user of more optimal ones?
I could see plenty of performance, troubleshooting etc. questions being avoided this way.
On another note, keeping this in mind, the BIOS might not be ACTIVELY involved once the OS has loaded, but appears to have quite significant PASSIVE influence on the system's behaviour because of the initial settings. That gives the BIOS (and it's settings) quite some weight or importance doesn't it?
The CPU's initialization is to look to the system's ROM BIOS for its first instruction in the startup program. The ROM BIOS stores the first instruction, which is the instruction to run the power-on self test (POST), in a predetermined memory address.
POST begins by checking the BIOS chip and then tests CMOS RAM. If the POST does not detect a battery failure, it then continues to initialize the CPU.
And you are right, the inital business that the BIOS does is very important. Without it, we would not have workable computers as we know them today. They would just be hardwired boards and weigh a few tons each. Personnally I would not want one of those.
There no doubt is a case to be made for this. On the other hand some may say that if they set something a certain way they may want it that way and not have to be warned all the time. And when it comes to "optimal" settings, many might say "what exactly is optimal". I know what you're getting at here KGG, and certainly it could be done. Its just it probably comes down to there is no "right" answer or one that is acceptable to all. So maybe the feeling is "if you set something a given way then you must either want it that way, or if you don't then it is your screw up.:confused:Quote:
Wouldn't/Shoudn't this be an area to address, i.e. wouldnt' the manufacturer of OS, vidcard, ram etc. have a routine verifying these settings and either change or advise the user of more optimal ones?
Oh it is still important, at least to a certain extent and/or in certain instances. Heck, at a bear minimum it is at least significant in that it kicks the whole show off. And if one were to happen to experience a bad bios flash update then suddenly the lowly bios (or lack there of ;)) would become VERY important.Quote:
That gives the BIOS (and it's settings) quite some weight or importance doesn't it?
I'm simply saying that the system bios is far less important today than it use to be, and probably less important and less involved than many people think it is in the overall scope of what goes on (and how it goes on) in their PCs.
Yes, a separate sound card could qualify, in an older system where no Plug'n'Play is involved. Some old sound cards had no interaction with the BIOS, and had to have drivers loaded to function, or an initialisation program run to set them up with port addresses etc before even games that directly addressed the sound chips could operate them.Quote:
Originally posted by hongman
Maybe something like a sound card?
Also, how can a pc boot from USB? Where would it get the drivers from?
Once P'n'P or on-board sound comes in, the system BIOS gets in on the act.
To boot from USB, the BIOS only has to have an appropriate access routine to execute boot code located on a USB device once the USB support chip is operational. In this regard, booting from USB is no different to any other bootable device that the BIOS already knows how to use, like a floppy or hard disk. A device driver is only necessary where software does not itself know how to directly access a hardware device. Drivers are used extensively in Operating Systems etc so that the OS kernel doesn't have to be written to "know" about every device in the world - each device can be supplied with its own driver to "translate" between how the device works, and how the particular OS or other software works.
Ah, i see. I thought drivers were needed for the device to even work, much past anything other than powering up. Thanks for puttin me straight on that one.
So technically, you could boot off a pen drive? Hold a whole operating system on one? Well actually I suppose you could nowadays, the sizes are 1GB+...
Whilst on the subject...
Does anyone know of a good webpage that describes what the error codes stand for? I dont mean beep codes, but the actual number error codes.
One more thing. Are all POST routines the same, i.e do they all check for everything in the same order, etc., even from diffeent BIOS mfr's? Or are they all proprietary?
Thanks guys and gals
Hong
You do need code (ie. a set of executable instructions appropriate for the control of and/or communication with a device) "somewhere", but by and large it doesn't matter where this code resides. It could be in a bios or firmware, in a formal driver, within the basic core (or kernel if you will) of an OS, in an application. As long as it is in one of these places (within certain bounds) and common rules (so to speak) have been established so that the means to use/run this code are known, that's all that matters in the final analysis. Does that make sense?Quote:
I thought drivers were needed for the device to even work, much past anything other than powering up.
It's possible, sure.Quote:
So technically, you could boot off a pen drive? Hold a whole operating system on one?
No. You will find a lot of commonality though between different bios. But they aren't all the same, don't need to be, and it wouldn't be appropriate for them all to be the same (because of difference between systems, in particular with regard to the motherboard configuration and components).Quote:
Are all POST routines the same
Goose, what did you mean here by "not checked"?Quote:
How about some examples of what would not be checked by BIOS as it is checking the Computer out