A common interview question for software developers is: what happens when you navigate to google.com.
When I was working with Linux kernel and coreboot I digged into the datasheet of my motherboard chipset to troubleshoot my unresponsive power button. It was pretty complicated, the kernel driver of the power button (yes, it's a thing!) actually first communicates to the EC/keyboard controller, and setup a GPIO input for the button to the appropriate mode and then hook an interrupt handler to it, finally it reroutes the interrupt of the EC to southbridge to generate an ACPI power-managerment event (PME), which triggers the actual hardware wakeup from suspend (it's not a standard x86-compatible machine although it uses x86 peripheral chips). If UEFI/ACPI is involved, the whole process would occur at a different layer.
So I started to think often since then: "What happens when you press the power button" can be the hardware-equivalent to that interview question. It seems to be a good question for a variety of hardware engineering fields, including simple embedded systems and complex computer systems.
I got asked a similar question from a devops/sysadmin point of view in an interview - If you enter 'ssh somehostnamethatisupandyoucansshto' what happens? I like this sort of question since it has no right or wrong answer, is a good way to get a feel for the breadth and depth of someone's knowledge and also how good they are at getting it across to others.
This kind of glosses over the actual boot loading part, imho.
We published a very similar article a few years ago, but as we (NeoSmart Technologies) are bootloader people, there’s a lot more emphasis on that part of things.
I'd like to see a description of the real boot process: the one that starts from cold silicon, and the Management Engine fetching its first instruction, as it brings up the main CPU.
When the CPU is switched on, it's put into a very very basic mode. Caches and peripherals are not available, only the registers on Core 0. A very special sequence of instructions hardcoded into the CPU runs to activate the caches and use them as memory. These instructions have no heap and stack, only a few dozen registers to work with. Since this is before the CPU is properly initialized, it has access to shadow registers and other unseen CPU internals for memory.
Once the caches and some CPU-internal peripherals are active, the next stage is loaded. At this point the L1 cache is used as RAM, this code will activate some parts of the system bus and begin training of the PCIe and DDR bus as well as bringing up the chipset, if necessary. This is where the Management Engine first runs.
The firmware looks for the BIOS on it's bus, I'm not certain on how it's connected but it's likely part of the I2C or SPI busses. Once that is loaded up, the firmware loads and activates the RAM and disables the Cache as RAM. Then the BIOS/EFI is invoked via the reset vector mentioned in the article.
The BIOS/EFI brings up the remaining parts of the CPU and Chipset while initializing and setting up the power and CPU clock. It will iterate the PCIe, USB and SATA busses, bring up the VGA graphics (or an EFI driver for graphics if available), connect up any missing devices on the SPI and I2C bus and setup any missing parameters (DDR RAM, CPU and other overclocks happen here if they are setup in the BIOS)
Once the BIOS has setup the device tree, it generates the ACPI table and other memory structures in memory, looks for the boot device and loads up the first applicable bootloader. The BIOS hands of to the OS and bootup is complete.
Atleast, this is the process I recall from my computing systems course.
Good summary! There is a coreboot video that talks about exactly this process (although very brief) you've described, "coreboot: x86 system boot and initialization", it presents a step by step procedure with a descriptions of various steps (DRAM init, Northbridge/Southbridge init) necessary to bring the system to point where it can boot OS. https://www.youtube.com/watch?v=xc08SN6Dhz4
> Once that is loaded up, the firmware loads and activates the RAM and disables the Cache as RAM.
This is an interesting step.
Initialing the memory controller and activating RAM is a difficult process on modern hardware. When the computer first boots with a fresh RAM module, BIOS needs to "train the memory" to make it usable. "Training the memory" means commanding the DDR controller to perform a series of testing to find the suitable operating parameters (e.g. latency) for the RAM, which is required to overcome the hardware variation on the electrical level. It's a combination of heuristics and lookup-tables, which can partially explain the variance of compatibility of RAM and different motherboards. It's also why the computer may have 10 seconds of apparent "black screen of death" on boot if you just updated BIOS (or installed a set of fresh RAM), which can be scary ;-).
On many platforms there is no free and open source implementation and coreboot developers had to reverse-enginner Intel's blob.
It's not all BIOS updates either, in my experience. Only those that affect parts of the firmware inside the CPU since the BIOS itself is way to late in the process. (ie Microcode updates, IME/AGESA/PM updates, etc.)
Personal experience confirms this somewhat, as boot after BIOS update can take 15 seconds or 1 second, depending on the update.
I am wondering whether voltage is stable at the very beginning when fans and disks spin up (as their coils are almost like a short) and capacitors are filling up. How do ICs Deal with initial voltage drops? Do they wait for things to stabilize?
On the motherboard power connector, there's a pin called "power good". The controller chip in a properly-designed PSU will determine whether the voltage rail has stabilized and only generates this signal when it did, the motherboard will only attempt to start when the "power good" signal is activated by the power supply, at this point all the inductors are saturated and capacitors are charged, so it's good to go for most boxes. Spinning fans are typically a non-issue. Also, the power circuitry on a modern motherboard has sophisticated control and protection, some can turn itself off or force-reset when significant over/undervoltage is detected.
However, if you have too many HDDs connected it could still be a big problem. When BIOS spins up the disk simultaneously, the inrush current of the motors is HUGE. In a good server setup, the disks have its own dedicated power supply, and a good disk controller will take care of it by not spinning all disks up at the same time. Some BIOS can also do that.
When I was working with Linux kernel and coreboot I digged into the datasheet of my motherboard chipset to troubleshoot my unresponsive power button. It was pretty complicated, the kernel driver of the power button (yes, it's a thing!) actually first communicates to the EC/keyboard controller, and setup a GPIO input for the button to the appropriate mode and then hook an interrupt handler to it, finally it reroutes the interrupt of the EC to southbridge to generate an ACPI power-managerment event (PME), which triggers the actual hardware wakeup from suspend (it's not a standard x86-compatible machine although it uses x86 peripheral chips). If UEFI/ACPI is involved, the whole process would occur at a different layer.
So I started to think often since then: "What happens when you press the power button" can be the hardware-equivalent to that interview question. It seems to be a good question for a variety of hardware engineering fields, including simple embedded systems and complex computer systems.