Week 2: Motherboards, CPUs, RAM, and Compatibility

A part can fit and still be wrong.

That is one of the first hardware lessons worth learning properly.

A processor may belong to the right socket family and still need a newer firmware revision. A memory module may have the capacity you want and still use the wrong DDR generation. A cooler may mount correctly and still be inadequate for the processor's heat output. A motherboard may have an M.2 slot and still reject the protocol used by the drive you bought.

So this week we stop asking only:

Does it fit?

and start asking:

What has to be true for this entire configuration to work?

The motherboard becomes our compatibility map. We will use it to connect physical fit, electrical signaling, processor platform, firmware support, memory type, power, cooling, expansion, and startup evidence into one system decision.

The system question

The question for Week 2 is:

How do we prove that motherboard, CPU, memory, firmware, cooling, and expansion choices belong together before we blame a failed part?

That question matters because hardware failures are often really compatibility failures, configuration failures, or installation failures wearing the same symptom.

A black screen does not tell you which one.

Compatibility is a chain

Use this model throughout the week:

physical fit
    ↓
electrical/interface support
    ↓
platform and firmware support
    ↓
power and cooling support
    ↓
correct configuration
    ↓
POST and runtime verification

Passing one layer does not prove the next.

A DIMM fitting into a slot does not prove the board supports that memory configuration. A CPU matching the socket does not prove the installed UEFI revision supports that exact processor. A successful POST does not prove the system will remain thermally stable under load.

Compatibility is a chain of claims, and each claim needs evidence.

How the chapter moves

Lesson 1 treats the motherboard as the place where system constraints become physical. You will read form factor, sockets, slots, headers, firmware controls, security features, and expansion paths as compatibility evidence.

Lesson 2 moves into the processor. Architecture, socket, cores, power, cache, firmware support, and cooling all matter, which is why reducing a CPU to one benchmark number is not useful technician reasoning.

Lesson 3 does the same with memory. DIMM versus SODIMM, DDR generation, ECC support, capacity, speed, and channel population form a memory configuration rather than a pile of sticks.

Lesson 4 is the compatibility lab. You will prove or reject a proposed configuration before installation by connecting every decision to documentation.

Lesson 5 starts with a system that receives power but does not complete POST. Instead of random part swapping, you will locate the earliest unsupported assumption and test one boundary at a time.

What you should be able to prove

By the end of the week, you should be able to defend a hardware configuration with evidence that shows:

• motherboard form factor and case fit;
• CPU architecture, socket, platform, and firmware support;
• RAM form factor, DDR generation, ECC mode, capacity, and channel population;
• relevant UEFI settings such as boot options, Secure Boot, TPM, USB controls, passwords, temperature monitoring, and virtualization support;
• appropriate cooling and CPU power paths;
• the role of common add-on cards such as graphics, sound, capture, and network adapters; and
• a troubleshooting path for a no-POST, memory, firmware-state, or board-level symptom.

The important part is not the completed table. The important part is being able to explain why the configuration should work and what evidence would make you change your mind.

One rule to keep

If a component needs unusual force, stop.

Computer hardware uses keying, latches, sockets, and mounting systems to guide correct installation. Force is not a compatibility strategy.

Verify the orientation. Verify the interface. Verify the documentation.

A five-minute check is cheaper than a damaged socket.