Back in grad school, I put together a presentation that talks about the boot process for a Linux machine, with a focus on what happens after the kernel takes over: http://people.cs.vt.edu/~scschnei/papers/boot_2up.pdf
One thing has always perplexed me: What is the very first thing that happens? The thing that tells the firmware to initialize? In other words, how does does the firmware "know" to initialize?
At a hardware level a bunch of things happen on a modern motherboard. A more simplistic example would be a cell phone or any SoC (System on a Chip) or microcontroller device. What follows is still very simplified and generic though.
When power is applied there is a PMIC (Power Management IC). This is a hardware integrated circuit that provides various features, among them are are the timings needed to power on the device. A power on sequence consists of the PMIC first receiving its primary power from a regulator on the system board, this usually triggers a hardware timer that waits a bit for the voltage to stabilize. Then the PMIC triggers the power supplies to other components. A modern SoC may need 3 or 4 different power supplies and these need to be 'enabled' in a specific order with specific timings. All this is managed by the hardware in the PMIC and would be the "trigger" that tells the SoC to fire up or more realistically just what is required to fire it up properly.
Once the voltages are supplied to the SoC several other things take place before the CPU comes online. Usually there is a bit of circuitry on the SoC called a PLL (Phase Locked Loop) that locks onto the system clock to avoid fluctuation. This can take some time as the system clock stabilizes after boot but even a stable stock takes a bit of time to lock onto. The PLL sub system also generates the various clocks needed by the SoC. The master clock from the system board may only be ~25Mhz but the PLL needs to generate various clocks for different parts of the SoC, maybe 1Ghz for the CPU, 100Mhz for the I/O, etc. Some SoC processor may actually start at a much slower clock rate and setup the PLL for its desired clock rate as part of the initialization process. Still others may have a very slow clock on chip that the SoC starts from to initialize itself before switching to the external clock.
Once all that is done, the CPU comes online. Sometimes this is prefaced by some support circuitry or microcode. For example it may fetch some data from memories off the SoC. Either way the CPU just starts executing at a known location so it all just starts with a single instruction. Usually you'd have a bootloader at the startup location that initializes just enough of the SoC to bring online additional functions. A common action is to setup external flash / ram then chain to a much more complex bootloader from the external flash.
In a modern x86 system there is more that goes on and much of what I described is more distributed to various components on the motherboard. Much of the initial startup is handled by what amounts to a microcontroller that lives inside the northbridge. It handles initial startup tasks before bringing the CPU online.
In one box I'm working with, a switch (whether mechanical, or an outboard management processor, a received network packet with a "smart" NIC, or otherwise) triggers a pin or signal on the processor.
This signal causes the processor to then perform its own start up, which then causes various processor-specific initialization, and then causing the processor to load its soft-loaded firmware code from a SROM, and to jump to the start address for the console firmware.
The firmware then performs more configuration and testing, and which eventually gets around to allowing the user to enter commands, or to trigger an operating system bootstrap by finding and loading blocks from a specified boot device.
The SROM implementation allows the firmware code to be more easily upgraded.
This sequence is usually covered in a processor technical manual, for whichever combination of processor and main board you're looking at.
Think of an old-fashioned tape computer. You feed the computer the tape, which causes the computer to do this or that in memory.
Initially, it knows nothing, but it is built to read in the tape, starting from the beginning. Then from there, what it reads on the tape controls what happens next.
You've gotten a lot of comments on this, mostly because you've asked a very open-ended question. Let me try to offer my interpretation to the question.
There are a bunch of active parts on the mainboard even when the power is off -- for example, your clock. You wouldn't want to reset the clock every time you power off, or even every time you unplug -- it lives on a battery while you're not looking. Some things like BIOS passwords also lives on that same battery -- so, at least, it used to be the case that when you wanted to bypass someone's boot password, you would break into the case, pop out the battery, unplug, wait five minutes to make sure that everything is dead, pop the battery back in, and start up from scratch. It's been a while since I last had to do that though. ^_^
The moment you press the power button, what you are really doing is completing a circuit between two pins exposed on the mainboard. Your power button literally has wires connecting to a socket which sits atop those pins. One of those pins has a voltage, one of them expects it, so the very first thing that happens is, "a burst of current flows from pin A to pin B." The motherboard is an electronic system which is already "on", and which is expecting this and waiting for it. (And you can trigger it with a screwdriver in a pinch.)
So that is "the thing that tells the firmware to initialize." To be fair, it might have a whole cascade of effects -- it might have to trigger the power supply or so, has to get the fan on the CPU running and then the CPU itself needs to start from a predictable state, and the mainboard needs to load its own firmware -- but the basic idea here is to just have a circuit which knows what this one little current pulse means.
The thing that tells the firmware to initialize? In other words, how does does the firmware "know" to initialize?
The firmware is just software that is executed by the CPU. The question is, how does the CPU know how to find and execute execute the firmware
From the article: The motherboard ensures that the instruction at the reset vector is a jump to the memory location mapped to the BIOS entry point.
The motherboard hardware ensures that the firmware is mapped into memory and that the reset vector points to its entry point. The CPU loads the reset vector into the EIP and starts to run the firmware.
It will run whatever is in the flash chip. That one is generally written to outside the system's control.
On modern PC mainboards with SPI flash (8 pins), there's often a set of pins (also 8) in close proximity to the flash chip - attach an external flasher to that, and you can write the flash while the PC is turned off.
The alternative would be to write the flash before it's put on the board, but which method is chosen is an implementation detail.
You're thinking about 10 steps ahead of this guy. He's just confused about the 'reset' vector being hit even when the computer is NOT explicitly reset, just when it's turned on for the first time, or powered on after being off.
That is to say, the reset vector is a pointer or address where the CPU should always begin as soon as it is able to execute instructions.
In other words, people who have lots of experience in this stuff gloss over the fact that "reset vector" doesn't mean reset at all, it actually means "whenever it's turned on, it jumps to this address and starts executing instructions".
In C, a "null pointer" (NULL, (void *)0, etc.) does not necessarily correspond to an address with all bits zero.[1] The compiler translates any pointer constants with a value of 0 to an invalid address appropriate for that machine.
I haven't verified this, but I could see this being used by microcontroller compilers, where address 0x0000 is often a memory-mapped register.
Also the C null pointer on modern system is the logical (virtual memory) address which is not necessarily mapped to 0x0 physical address - in fact, to trap the null pointer access, this page would be left unmapped so the OS receives a page fault. This means that before virtual memory is set up (or if a page is mapped for logical address 0x0), 0x0 is a perfectly valid memory location, both for data storage and executing instructions from. Basically, the null pointer "error" is trapped by the OS at a higher level.
In fact, there's an entire class of kernel exploits where if you know a certain kind of behavior will cause the kernel to dereference 0x0, and that system allows you to mmap the lowest page in your virtual address space, you can take over the machine.
I used 0 as the example because the 8bit chip I was thinking of (the Z80) used that. But the exact address isn't too relevant, the basic idea is that the CPU has a default state for the instruction pointer, and can get things going from there.
The computer begins with the CPU. When the CPU starts running (which basically happens as soon as it receives power and is reset with the RESET pin), it begins to pull instructions from memory and execute them. Where it starts in memory depends on the individual CPU, but in the case of the Z80, it simply begins at memory address 0, instead of using a reset vector like many other CPUs do. This means that any computer using the Z80 must have a ROM chip at memory address 0 which gives the initial start-up instructions to the Z80."
Also - the memory map during boot time is broadly unrelated to the per-process memory map during OS runtime. Also, if you branch to unexpected memory addresses, you deserve all you get. Also, on a processor with privilege isolation, your ring3 user process can't just cause a reboot.
No, it may be just a memory address like any other (it can also be a register or other special address). The reason it's a problem in normal programs is because there usually isn't code there (and with memory protection, you probably aren't allowed to access that space, which is the error you often see).
The CPU doesn't care if the address is all 0s, that's not special to the CPU. So when it turns on it just starts executing at some hard-wired address. That could be 0x0000, 0x8000, or it could be something really random like 0x48C4. Somewhere in the chip's documentation it says what the address is. Once the CPU has power, it loads the first instruction from that address, and then it executes everything as normal.
So you wire up the computer so that some little piece of ROM (for example the BIOS) sits at that address. When the chip turns on, you know what instructions it will start executing.
Once things are going, you could set things up to be more complicated (such toggling pins to signal the ROM chip to stop listening so you could map normal RAM into that address), but that's the basic idea.
To be more specific: the CPU has circuitry that, upon power-up, either a) sets the program counter to a specific initial address (like all zeros), or b) fetches a word from a specific location in read-only memory (the "reset vector") and loads it into the program counter.
Typically, the initial program counter value points to startup code in read-only memory. (On PCs, "read-only memory" is the BIOS, on most 8-bit game consoles, it's the chip in the game cartridge, on microcontrollers it's the PROM or flash memory where the firmware is stored, etc.)
It wouldn't make much sense to start executing code out of RAM on startup because the contents of RAM will be random garbage. Powering up an old game console without a cartridge does something similar--when there is no ROM chip physically connected to the CPU, all attempts to access ROM return 0x00 or 0xFF or something random, and the CPU just executes bogus instructions until it's powered off.
It's even more interesting than that. One of the things that the BIOS has to do, if I recall correctly, is to set up the memory controller. Until it does that, it's only able to execute out of registers and cache, no RAM.
If you're interested, Coreboot (an open source BIOS replacement) has interesting information on this.
I think my answer if asked this question in an interview would be "A trainwreck of legacy (in)compatibility layers designed to keep grandpa from losing his teeth after he's been dead twenty years.".
A Few times I have prised out the Eprom off the motherboard and re-flashed it with my own small programs for a super-fast embedded system or game. (the eprom is ussally the only socketed item on the motherboard apart from the CPU)
The main problem is not overwritting the BIOS routines which, unless you rewrite them all (like linux of windows do) you still need to use (nothing here has really changed since 1981 and you can use anything that produces 16 bit code such as Turbo C, Assembler or Pascal)
Usually there is plenty of spare EPROM space you can find and as your running in 16 bit mode this is enough for something like space invaders :-)
PC Motherboards can usually be blagged for nothing, so its a great way to do low level experimenting.
