Printable View
KiloBytes but modern bios chips can be in the 2MB range.Quote:
Originally posted by hongman
And that area of memory - the first 64KB... is it KiloBytes of just Bytes?
The BIOS Chip
Quote:
The capacity of BIOS chips is measured in Megabits (Mb). Most BIOS chips these days are 2Mb (256KB) in size. These higher capacity chips allow the manufacturer to offer more features than is possible with the smaller 1Mb chips.
Thank you for clearing that one up!!
I'm curious as well now that Greengoose mentions it...how will there be a future without BIOS's?
One thing I think needs to be made clear here. The bios and cmos memory area being talked about here in these definitions and such refer to the main or overall "system" bios and cmos (or nvram if you like) memory. As has been noted elsewhere, there can be (and are) other bioses in one's computer. And since "CMOS" is a particular process used to make semiconductors/ICs, the CMOS type memory used by (in conjunction with, as a storage place of certain information/settings for) the system bios is not the only place you'll find CMOS technology or memory in one's computer. Anyway...
Before I forget let me throw in one point here... The system bios (any bios for that matter) is code/instructions. The system bios, the bios chip, has no instruction execution capability of its own. It requires the/a cpu to execute the code it contains. So at initial power on the the cpu must be initialized successfully before any bios operations can take place. Without a functioning (at least to some extent) CPU the bios is just little more than a chip with cpu instructions sitting in it.
A couple changes/additions to the Bigelow info...
The inital initialization of the CPU and chipset is done prior to the POST (prior to the bios code even beginning). This has to be the case (again, since the bios is just code).
What Bigelow describes as the "P.O.S.T." function is quite overstated. That true POST sequence is a very quick and fairly basic inventory and test of certain hardware. Bigelow seems to have lumped all initialization and inventoring type functions performed by the bios under the POST category, when in fact the POST (sequence) is just one (the initial) part of a process that extends after the true POST has been done. It would be more accurate if Bigelow had called the function/heading "System Initialization" rather than "POST". The POST is part of the sequence of things done by the bios under that category of system initialization. But most of the things that happen from the time the bios code first starts executing until it finishes its job are not part of the POST though. Ya might say I'm being picky here, but...
And while I'm being picky (;)) let me pick on one other thing. The bios routines do not "proceeds to boot the OS from an available disk". The bios code "begins" (or tries to) the process of booting an OS. What the bios code actually does is go sequentially through the list of boot devices (that the user has specified, and which are stored in the cmos data area) one by one checking to see if there is viable boot code in the proper place, and then loading and passing execution control to the code in this boot record. In the case of, say, a hard drive this would be code in the Master Boot Record of the drive. And in the case of a hard drive this code would not be operating system boot code, but meerly code that would in turn try to locate, load and start execution of the actual OS boot code (in the partition/volume boot record). Like I said, I'm being picky but...
And finally, on the stuff about the bios sitting between the hardware and OS or other software... Not to beat a dead horse but again, with currrent/today's systems the role of the bios after it has initiated the boot process has been tremendously reduced. Once the system is running (so to speak) the bios routines are much less used or relied on, and largely out of the loop (and not in control).
OK, enough for now. Again, good thread!
It's not that there won't be bioses per se. But what will be (and has been) happening is that the code and functions performed by the code in the "system bios" will be offloaded. Instead of being centralized on one chip, it will be distributed more and more to other hardware components (chips, devices). For instance, instead of having the system bios handle all video related needs, you offload the code and functions to video card itself. Or, you resonsibility and handling of i/o operations between a disk drive and the OS and offload these to the OS code and hardware/firmware on the device. Just two quick examples.Quote:
how will there be a future without BIOS's?
There are actually valid reasons and benefits why the "system bios" can not and should not remain the "master and commander" it once was. Given the increasing demands, complexities and capabilities of the technology (hardware and software) it has become and is becoming less and less efficient and even practical to have the system bios be and do what it once did.
Wow.
I was wondering when you were going to make your mark on this thread ;)
Ok so the BIOS Chip holds code for system initialization, that the CPU will execute, and the CMOS holds other settings to do with booting, like boot sequence, motherboard devices, etc.
Is that correct, in a less-in-depth sense? I need to grasp this bit before I can concentrate on the individual roles of everything else.
DR, so accoring to what you were saying, the CPU actually initializes itself (to run the BIOS code)? I was under the understanding that the BIOS initialized the CPU, but then again what do I know :p
Thanks ppl
HOng
PS After this thread I best be an expert on this!!:D
Interesting............so is this code not part of the operating system per se be it an initiation code to get the OS running or is it an entity unto itself i.e a bootstrap if so where does it originate from ?Quote:
In the case of, say, a hard drive this would be code in the Master Boot Record of the drive. And in the case of a hard drive this code would not be operating system boot code, but meerly code that would in turn try to locate, load and start execution of the actual OS boot code (in the partition/volume boot record)
No. What actually happens is that when power to the system is turned on, the power supply comes up and does some self tests (and makes sure power levels are up to snuff). During this time the motherboard chipset has sent a signal to the cpu to put it in a reset state (on, but kind of in a holding pattern so to speak). Then when the PS is satisfied things are ok with it it sends a sinal (what's called the Power Good Signal) to the CPU that tells it to got ahead. Then at this point the CPU goes out to a predefined and specific memory location (as per convention) on the BIOS' rom and fetches it's first instruction to execute (which is nothing more than an instruction that causes a jump/branch to another memory location where the true beginning of the bios startup code is). And things progress from there.Quote:
the CPU actually initializes itself (to run the BIOS code)?
Yes, the CMOS holds settings, some hardware configuration info (not all) and the system time/date. The bios (chip) does hold the code for system initialization (speaking broadly, and which includes the POST functions, startup screen functions, etc, etc) and inventorying a lot of the hardware, plus:Quote:
Ok so the BIOS Chip holds code for system initialization, that the CPU will execute, and the CMOS holds other settings to do with booting, like boot sequence, motherboard devices, etc
- The code used to provide the interface to update the cmos settings.
- The various low level routines/functions (system services as referred to in 104456's post) that others have referred to, and which can but may or may not be used by the OS, programs, etc.
And it can and often does contain code that:
- Enables a bad system bios flash to be recovered from (often referred to as "boot block" code.
- Enables a system bios system bios flash to be initiated.
Thanks DR.
Feels like I am finally getting somewhere now. Under the generalisation i posted earlier, I can now use that to build upon the more 'complicated' things mentioned in this thread.
Thank you all!!
Hong
104456,
"Bootstrap" code is probably a decent description. Again, in the case of a hard drive (things differ with other bootable devices), the code in the MBR, the code the bios loads and kicks off, is not specific to an OS per se. It is generic, and functions to then find and load OS boot code in another boot record in a partition. Now of course it "could be" anything viable ya wanted to put in there.
When one is using, say, a disk overlay, the disk overlay puts its code in to the MBR (so it can hook in to things right off the bat). Same with something like third party "boot loaders".
When you do, say, and FDISK /MBR what it is doing is putting a generic set of boot code in the MBR (that then goes off and does what's described when run). It is not specific to say Win95 or WinME or WinXP. Their specific boot code is loaded in to partition boot sectors/records (in the base case in the active primary partition). In the case of something like Win9x/ME (even dos) the SYS command is one way to update this code and put in place an OS boot record. The MBR code kicks off this boot code.
Through this thread I have noticed a few bits and pieces, one of which is mentioned above. My question is, why does it have to fetch one bit of code which then justs points it into another bit of code? Point being, why doesnt it just go straight to the 'true' beginning?Quote:
fetches it's first instruction to execute (which is nothing more than an instruction that causes a jump/branch to another memory location where the true beginning of the bios startup code is)
So it is a seperate entity in itself.Quote:
Bootstrap" code is probably a decent description.
I suppose this would be more apparent in say a network computer where the boot code is so I understand initiated from the network card.
It's a convention that was established a long time ago. The idea behind this is that by using a consistently small area (no more than 16 bytes), reserved at a specific location, and containing just the jump instruction then it would never matter how big or where a bios' real and full code began. I gives bios manufacturers flexibility. All they have to worry about is making sure they place the proper jump instruction (pointing to where they want execution to continue from) in the designated location. And on the flipside, the cpu manufacturer's know to program in to their processors to initially just go to that location and execute what's there.Quote:
why does it have to fetch one bit of code which then justs points it into another bit of code? Point being, why doesnt it just go straight to the 'true' beginning?
Oh I see...
Thanks
Hong:)
So BIOS as small as it is has to verify all is well on the computer on startup as it wants to know if everything is OK. Then it hands control to the OS.
Looks as though there is a potential for a huge amont of error messages. Different ones that can be generated as a result of finding something in the hardware that is not right.
And this is only a small Part of the overall BIOS picture?
"All" well? There are bounds. Not "all" hardware is checked/verified, even inventoried. And some of the checks/tests are not that extensive. The system bios looks to know about certain things (hardware), or at least certain things about them. And it looks to know certain things are functioning to a certain degree. I guess what I'm saying is that it would not be correct to assume the system bios checks or worries about every pieces of hardware, when its done doing its checks/tests can one conclude that all the hardware is indeed "fully" functional. Make sense?Quote:
So BIOS as small as it is has to verify all is well on the computer on startup as it wants to know if everything is OK
Just one example... The bios checks how much system ram is present, and verifies that the addresses are indeed accessible. But this is not an extensive test at the end of which one can conclude their system ram is fully functional and will produce error free operation.