What actually happens when a PC is turned on?

[dicky96]

I know this sounds like a dumb question but I just can't seem to find a proper answer to this by googling.

For example I found this description of the sequence of events on webopedia, and if you read it, you find it contradicts itself

When the computer's power is first turned on, the CPU initializes itself, which is triggered by a series of clock ticks generated by the system clock. Part of 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, checking the inventoried hardware devices (such as the video card), secondary storage devices, such as hard drives, ports and other hardware devices, such as the keyboard and mouse, to ensure they are functioning properly.

Once the POST has determined that all components are functioning properly and the CPU has successfully initialized, the BIOS looks for an operating system to load.

So OK that tells me that the CPU initialises itself - but then the BIOS continues to initialise the CPU? But It said the CPU intialises itself, how can the BIOS continue to initialise the CPU if it wasn't already initialising it before it continued to do that??


Other sources of information say that it is the Super IO chip which initialises the CPU Some tutorials even call it the 'start-up chip'

Do you see why I am so confused by all this?

OK so can some kind person explain or post a link that explains what is actually going on at a hardware level when power is applied to a motherboard?

Does the CPU simply go to some fixed address at the top or bottom of the address space like old 8 bit CPUs and microcontrollers did and read a jump vector from there which presumably points to the start of the POST routine? .

Or does the microcontroller in the Super IO start to execute code by going to some fixed address and reading a jump vector from the BIOS (so the BIOS or part of it contains 8051 code or whatever the Super IO microcontroller supports)?

Is the Super IO then initialising the hardware in some way, or is the CPU initialising the hardware?

And actually it is the Super IO that runs the POST program, or the CPU?


I just can't get this clear in my head. And if I don't understand exactly what is happening when I hit the power button then it makes it a lot harder to understand what isn't happening when the motherboard will not POST.

[Curious.George]

Re: What actually happens when a PC is turned on?

I know this sounds like a dumb question but I just can't seem to find a proper answer to this by googling.

The startup sequence for ANY microprocessor-based device essentially has to:

• verify the processor is working
• verify the initial program (BIOS/POST) is intact
• test any configuration hardware
• configure that hardware to access the balance of the system resources (which can include "main memory")
• test main memory (before relying on it for further testing)
• test known peripherals
• scan for optional peripherals
• configure those peripherals
• test the peripherals as configured
• load the application (which is the "OS", if its a PC)

How effectively these tasks are done depends on the design of the hardware and the skill of the programmer. And, the goals of the system manufacturer! (e.g., do they want to actually HELP you repair a defective system? Or, do they just want to point out "basic problems" to explain why the system will REFUSE to boot?)

[snipped naive startup description]

Does the CPU simply go to some fixed address at the top or bottom of the address space like old 8 bit CPUs and microcontrollers did and read a jump vector from there which presumably points to the start of the POST routine? .

In general terms, every "processor" has a predefined mechanism for reliably fetching the first instruction from memory. Typically, there are also provisions to fetch the initial stack pointer as well as mechanisms that ensure interrupts can't be processed before the processor is "ready" for them (which is something the programmer decides). Otherwise, the interrupt can cause the processor to execute code from some indeterminate location -- before it even knows that there is code there to execute! (i.e., the processor goes off to la-la-land before it's even had a chance to initialize itself)

Or does the microcontroller in the Super IO start to execute code by going to some fixed address and reading a jump vector from the BIOS (so the BIOS or part of it contains 8051 code or whatever the Super IO microcontroller supports)?

Is the Super IO then initialising the hardware in some way, or is the CPU initialising the hardware?

And actually it is the Super IO that runs the POST program, or the CPU?

The SuperI/O is just a collection of "standard" peripherals that all/most PCs seem to include: serial/parallel ports, floppy disk controller, keyboard/mouse interface, NVRAM, RTC, etc. PC's suffer from a lack of variation -- they all use the same "devices" connected to the processor in much the same way they've always been. E.g., every UART will mimic the behavior of a 16450 (which, in turn, mimics the behavior of its predecessor, the i8250). So, why not lump all of them into a single chip to save board space and manufacturing costs?

Nowadays, many peripherals actually include processors of their own (NICs, HBAs, etc.). But, that's just because a sequential state machine is a more effective way to design those devices than "dedicated logic". The software for these peripherals typically resides on (or near) each and may take the form of ROM/FLASH on/in the chip or slushware that is loaded by the main CPU as part of the peripheral's initialization process.

The main CPU does the initialization (i.e., executes the startup code) for the system. But, there is nothing that REQUIRES this to be the case! It's just the most straightforward, "least inspired" approach.

An easy (tool-less) way to get a feel for what the machine is (or isn't!) doing is to look through a list of beep codes (or, indicator lights) to see what types of errors it will report. Then, do things to trigger those errors and see if they are reported. E.g., pulling the RAM should result in a memory error. If you DON'T get a report of that, then you know the code hasn't made it to the "memory test", yet.

[dicky96]

Re: What actually happens when a PC is turned on?

In general terms, every "processor" has a predefined mechanism for reliably fetching the first instruction from memory. Typically, there are also provisions to fetch the initial stack pointer as well as mechanisms that ensure interrupts can't be processed before the processor is "ready" for them (which is something the programmer decides). Otherwise, the interrupt can cause the processor to execute code from some indeterminate location -- before it even knows that there is code there to execute! (i.e., the processor goes off to la-la-land before it's even had a chance to initialize itself)

That is a very good description and makes perfect sense to me - especially the stuff about interrupts etc.

The SuperI/O is just a collection of "standard" peripherals that all/most PCs seem to include:

Yes I get that. Why do some videos on youtube regarding laptop motherboard repair (eg this guy - electronics repair school) who obviously know what they are doing refer to this as the 'start-up chip'.

I've also seen 'power up sequence' tutorials that show the role of super IO during power on in respect to signals to turn on various power supply voltages. Further I've read that the Super IO also act as a 'reset controller' for the CPU during the boot process.

Another thing that I don't quite get - if the CPU loads initially pointers (code, stack etc like you say) like any microprocessor, how does it do that unless some other hardware is already initialised to enable that to happen (as the BIOS is not directly on the CPU address and data bus but is on an SPI or LPC bus)

I guess really I am trying to understand the relationship between the Super IO and the CPU during the power on process, and the sequence of events that (should) occur.

An easy (tool-less) way to get a feel for what the machine is (or isn't!) doing is to look through a list of beep codes (or, indicator lights) to see what types of errors it will report. Then, do things to trigger those errors and see if they are reported. E.g., pulling the RAM should result in a memory error. If you DON'T get a report of that, then you know the code hasn't made it to the "memory test", yet.

Sure that makes sense. Also I found that using POST diagnostic cards helps to some extent. I can handle those sort of faults.

The ones I am struggling with (and I believe I am struggling due to gaps in my own knowledge) are motherboards that do not post and do not beep.

Or for example I have a board at the moment that will beep when there is no RAM fitted but won't beep and won't boot as soon as any (known good) RAM is fitted. The POST analyzer tells me that one hangs when it tries to transition protected mode/real mode (with RAM fitted). Actually from what I am researching now regards boot sequences that one could be something to do with the Super IO

The worse ones are those that clearly have good voltage rails 3.3V, 5V, 12V, Core, VRAM etc) with a known good CPU fitted and still won't beep.

I have a pile of motherboards on one side that have these type of faults, and as I learn more I go back in my spare time and try to fix them. Sometimes I find that knowledge gained let's me fix boards I previously failed to fix, so this approach appears to be working

Thanks for your advice on this thread.

[Curious.George]

Re: What actually happens when a PC is turned on?

The ones I am struggling with (and I believe I am struggling due to gaps in my own knowledge) are motherboards that do not post and do not beep.

Or for example I have a board at the moment that will beep when there is no RAM fitted but won't beep and won't boot as soon as any (known good) RAM is fitted. The POST analyzer tells me that one hangs when it tries to transition protected mode/real mode (with RAM fitted). Actually from what I am researching now regards boot sequences that one could be something to do with the Super IO

Sorry, I don't fix motherboards -- I consider PC's to be "tools" and don't fret with them when they fail (just like I don't bother repairing hammers and circular saws that break from use).

Attached is the "readme" for Pascal's Tiny BIOS. You might glean some information about how IT works and try to generalize that to COTS BIOSes. It's a source code product intended for folks building embedded devices that are based on x86 processors (capable of hosting MS OS's).

I believe the old IBM AT BIOS source code is also available (google is your friend). They might give you a more detailed idea as to what MIGHT be happening at any given point in the process. Keep in mind that the specifics of YOUR particular BIOS may differ so none of these can be treated as authoritative references.

But, you may be able to rule out certain issues just by noting how far the process appears to have progressed (e.g., the BIOS ROM checksum has probably been verified by the POST so you KNOW that the software CAN execute when called upon to do so... and, RAM probably has been tested...).

Look carefully through the error code listings for your BIOS and see if you can sense a pattern in the error code numbering that might be suggestive of the order in which the tests are performed.

[piernov]

Re: What actually happens when a PC is turned on?

There's a lot to explain, but I'll try to keep it short and focus on the main points for the questions that were asked.

Just to make things clear, what people call "startup chip", "multicontroller", "Keyboard Controller"/"KBC", "Super I/O"/"SIO", "Embedded Controller"/"EC" is essentially the same thing on modern PC.
I prefer calling it the "EC" (or Embedded Controller) when talking about a laptop, because it does a lot of various things and it is programmable. On a laptop, it'll be the ITE ITxxxx, ENE KBCxxxx, SMSC MECxxxx chip. The SMC on Macbooks has a similar role, although it doesn't have a keyboard controller in it. It's a microcontroller that has its own firmware and executes it as soon as it receives power (and its reset signal is deasserted), independent from the CPU.
On desktops (mostly low/mid range boards), it does less things and is usually not programmable, Winbond or ITE IT871x/872x chips are common. On older board it also had a floppy disk controller in it.

Among its various roles, one of it is to manage the start of the power sequence. ie. what happens when you press the power button. The power button is directly connected to it (in most cases). The southbridge and then northbridge also help in this process. The goal is to setup all the different power rails of the machine, start the various clocks and deassert the reset signals of the various components.
The final step (more or less) is to get to CPU reset signal deassertion.

Once the CPU reset signal is deasserted, power sequence is (mostly — maybe excluding GPU) done. The CPU starts executing instruction. Its instruction pointer is reset to the reset vector value when the reset signal is asserted. So after deassertion, the CPU reads its first instruction to the memory address given by this specific value.
The CPU tries to load the data at that address, and so asks the northbridge (which contains the memory controller on older platform, it's not the case on newer platforms since it's inside the CPU but let's keep it simple) to give him what's located there. The northbridge knows that this address is not supposed to be read in the main memory (RAM), so it forward the request to the southbridge. The southbridge knows that it is supposed to read that from the BIOS. BIOS may be configured to be on the FWH bus, the LPC bus or the SPI bus. Southbridge then sends a request on either of those bus to read the data stored in the ROM. And when the ROM chip answers, the data goes all the way back to the CPU to be executed as an instruction. Instruction is decoded, executed, and the instruction pointer is incremented to read the next instruction, and so on.

On modern initialization sequence, one of the first thing the BIOS does is switch to protected mode ("32-bit" mode). The CPU indeed always start in real mode ("16-bit" mode) like back in the good old days. And it'll also set up some internal CPU stuff. You can call this step the "CPU initialization".
After that it'll do some minimal initialization to the EC, to the northbridge and to the southbridge. Then comes RAM detection and initilization. Note that RAM is still not used at all to this point.
Once RAM is initialized, the BIOS is copied into RAM, and then CPU continues the execution from the RAM. The remaining parts of northbridge/southbridge/EC are initialized to be then able to detect and initialize the peripherals connected to them.

Anything that goes wrong there can cause it to stall. POST codes can be output at any point in time as soon as the BIOS is being executed, they're just a specific instruction of the CPU.
Note that the POST codes are different from BIOS editor to BIOS editor, and among their different versions too. It's sometimes hard to find the correct POST code list.


Let me make it clear that what I call BIOS here is in fact *not* the "traditional" BIOS before UEFI. The "traditional" BIOS will not switch to protected mode as the first step of the process. I'm more talking about more modern software like the UEFI or Coreboot.
I use the word BIOS just because it's common to call the first piece of software that's executed by the CPU by this name.

[dicky96]

Re: What actually happens when a PC is turned on?

Thank you very much both Curious George and Piernov especially for that long and detailed description

Both posts are very useful in trying to understand this stuff. It suprises me how hard this sort of (basic) information is to find sometimes.

It certainly gives me more ideas about that motherboard that fails when switching to protected mode.

As I explained, I'm trying to fix these for 'training' purposes in my spare time (after I did some 'real work' to make money for the day lol) and not because they are worth anything. If anyone can suggest any other resources to help me in my quest I would much appreciate that.

One idea I had is to buy used working boards of the same model as the faulty ones from ebay, if I can find them cheap for like £20 or something, then use them to compare readings from a good and bad board, and maybe swap parts from one to the other until I find the faulty component and hopefully learn something in the process.

Rich

[dicky96]

Re: What actually happens when a PC is turned on?

Ohhh
When I was reading Piernov post again and searched to see what 'FWH bus' means, google told me how to get to Fort Worth on public transport!!

[Uranium-235]

Re: What actually happens when a PC is turned on?

T
Once RAM is initialized, the BIOS is copied into RAM, and then CPU continues the execution from the RAM.

I've actually had a computer, years ago I was fixing that said the bios is corrupt. I tried to reflash it with a cdrom containing only the bios file with a certain name. It worked, but the bios was still bad

turns out, the very first chip on one of the memory sticks was bad, it failed it's own integrity check in memory, but the chip was fine. However after my flash attempt I bricked the motherboard permanently.

[dicky96]

Re: What actually happens when a PC is turned on?

However after my flash attempt I bricked the motherboard permanently.

I recently bought an Eprom programmer and have successfully resurrected a few motherboards by flashing the BIOS. It more than paid for itself after the first two times i used it

Probably your board wasn't bricked permanently, you just needed a cheap external eprom programmer. And another PC......

[Uranium-235]

Re: What actually happens when a PC is turned on?

it was several years ago, and I didn't have the skills at the time to unsolder a chip