How a computer boots up
duartes.org
duartes.org
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.
If you're interested, Coreboot (an open source BIOS replacement) has interesting information on this.
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.
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.
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".
If you arrange matters so that until the CPU tells you differently, memory address 0x0000 holds your firmware, then all can proceed from there.
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.
(Unless you get lucky, and it's a branch-predict, that turns out to be an incorrect predict, and then flushes and re-branches into valid memory...)
I haven't verified this, but I could see this being used by microcontroller compilers, where address 0x0000 is often a memory-mapped register.
See https://blogs.oracle.com/ksplice/entry/much_ado_about_null_a... and https://blogs.oracle.com/ksplice/entry/much_ado_about_null_e...
(dkersten, I assume you know this, I'm pointing it out for the benefit of others.)
http://lateblt.tripod.com/z80proj1.htm
"What's Happening?
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.
So do new 8bit processors and almost all processors, x86 cpus still have a reset vector, its 0xFFFFFFF0.
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.
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.
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.
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.
[1] http://news.ycombinator.com/item?id=3120706 [2] http://news.ycombinator.com/item?id=3131380
Here's a video talking about inner workings of the boot process http://www.youtube.com/watch?v=X72LgcMpM9k#t=438s
url linked at 7min, but it's actually 3x15min talks. have fun watching them all :p
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.
How a computer boots up:
LI1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010