Firmware basics

Let's begin our October with some techs which sit between hardware and software.

 

 

Before we begin, thanks to you all and especially all my supporters.

THANKS:

You can also buy me a coffee -- HERE

 


 [ I do not own the above image. I stole it from the internet ;-) ]

Don't think much about the above image. I am just putting random interesting images.


* What you will learn here:

  • How your CPU communicates with different hardware (like your keyboard, speakers, printer, etc)
  • ROM, Device Driver
  • BIOS/UEFI, CMOS and RTC
  • Power-On Self Test (POST)
  • [BONUS] Useful time saving tech tips and tricks

 

[note: some concepts are not explained in dept for simplicity.]

 

 

* Introduction:

If you have a simple Computer without any Input/Output devices, I am sure it will bore you to death as there's no way to do anything with it. A PC needs devices such as keyboards and mice to provide input, and output devices such as monitors and speakers to communicate the current state of the running programs to you. A computer also needs permanent storage devices, such as solid-state drives, to store programs and data when you turn off the computer.


This article discusses in detail the software that controls a PC at it's core. Let's go straight to the HOW and WHYs.



* We need to Talk

For hardware devices like keyboard, monitor or a hard drive to work with a CPU, they must communicate via some kind of physical connection. More than that, these peripherals (usually) can’t connect directly to the CPU. This communication
requires a controller, a chip that connects the device to the CPU.


 

Let's no go deep into how the CPU is connected with the Controller and with different peripherals (I will keep this for another article).

For now, just swallow the concept that the CPU uses bus or special wires (address bus and data bus) to talk to the devices, BUT how does the CPU know what to say to them? How does it know all the patterns of ones and zeros to tell the hard drive it needs to send a file? Let's look at the interaction between the keyboard and CPU for insight into this process.

 

 

* Talking to the keyboard

The keyboard provides a great example of how the buses and support
programming help the CPU get the job done. Every time you press a key on your keyboard, a scanning chip in the keyboard notices which key you pressed. Then the scanner sends a coded pattern of ones and zeros—called the scan code—to the keyboard controller (chipset). Every key on your keyboard has a unique scan code. The keyboard controller stores the scan code in its own register (variable).

How does the CPU get the scan code out of the keyboard controller?
While we’re at it, how does the CPU tell the keyboard to change the typematic buffer rate (when you hold down a key and the letter repeats) or to turn the number lock LED on and off, to mention just a few other jobs the keyboard needs to do for the system? The point is that the keyboard controller must be able to respond to multiple commands, not just one.

The keyboard controller accepts commands from the CPU. The keyboard controller has its own codebook which stores all the valid commands. If the CPU wants to know what key was last pressed on the keyboard, the CPU needs to know the command (or series of commands) that orders the keyboard controller to put the scan code of the letter on the external data bus so the CPU can read it.

 

 

* BIOS

The CPU doesn’t magically or otherwise automatically know how to talk with any device; it needs some sort of support programming loaded into memory that teaches it about a particular device. This programming is called basic input/output services (BIOS). The programs dedicated to enabling the CPU to communicate with devices are called services (or device drivers, as you’ll see later). This goes well beyond the keyboard, by the way. In fact, every device on the computer needs BIOS! But let’s continue with the keyboard for now.

 

 

* Bringing BIOS to the PC

A talented programmer could write BIOS for a keyboard if the programmer
knew the keyboard’s codebook; keyboards are pretty simple devices. This begs the question: Where would this support programming be stored? Programming could be incorporated into the operating system. Storing programming to talk to the hardware of your PC in the operating system is great—all operating systems have built-in code that knows how to talk to your keyboard, your mouse, and just about every piece of hardware you may put into your PC. 

That’s fine once the operating system’s up and running, but what about a brand-new stack of parts you’re about to assemble into a new PC? When a new system is being built, it has no operating system. The CPU must have access to BIOS for the most important hardware on your PC: not only the keyboard, but also the monitor, mass storage drives, optical drives, USB ports, and RAM. This code can’t be stored on a hard drive or optical disc—these important devices need to be ready at any time the CPU calls them, even before installing a mass storage device or an operating system.

The perfect place to store the support programming is on the motherboard.
That settles one issue, but another looms: What storage medium should the
motherboard use? DRAM won’t work, because all of the data would be erased every time you turned off the computer. You need some type of permanent program storage device that does not depend on other peripherals to work. And you need that storage device to sit on the motherboard.

 

 

* ROM

Motherboards store the keyboard controller support programming, among other programs, on a special type of device called a read-only memory (ROM) chip. A ROM chip stores programs, services, exactly like RAM. ROM differs from RAM in two important ways. First, ROM chips are nonvolatile, meaning that the information stored on ROM isn’t erased when the computer is turned off. Second, traditional ROM chips are read-only, meaning that once you store a program on one, you can’t change it. Motherboards use a type of ROM called flash ROM, the same stuff that stores your data in your smartphone or SSD. That is why we call updating the BIOS firmware.

Typical flash ROM
 

Every motherboard has a flash ROM chip, called the system ROM chip because it contains code that enables your CPU to talk to the basic hardware of your PC. As alluded to earlier, the system ROM holds BIOS for more than just the keyboard controller. It also stores programs for communicating with hard drives, optical drives, display devices, USB ports, and other basic devices on your motherboard.

 

 

* UEFI

Modern systems use firmware programming called the Unified Extensible Firmware Interface (UEFI). Here are a few advantages of UEFI over the original BIOS in PCs:

  • UEFI supports booting to partitions larger than 2.2 TB
  • UEFI firmware is native 32- or 64-bit; this lets the manufacturers
    include lots of features for setup and diagnoses.
  • UEFI handles all boot-loading duties; no more jumping from boot
    sector to boot sector.
  • UEFI is portable to other chip types, not just 16-bit x86.

All current systems use UEFI. Many also provide legacy support for BIOS services in case you feel some retro gaming is in order. But a zillion older systems use the older BIOS. Most techs continue to call the support software BIOS, even though technically the terms differ. There’s no standardization on how to pronounce UEFI, by the way. Microsoft initializes it: “U-E-F-I.” Others say “you-fee” or “you-fie.” For a job interview, stick with initializing it. You can’t go wrong that way. 

 

 

* CMOS and RTC

Because the BIOS firmware is stored in ROM, and ROM is read only, it needs a place to store all its settings so they don’t have to be re-entered every time you boot your computer. That place is a tiny bit of RAM hooked up to a small battery to keep it working with the PC off. We call this memory the complementary metal-oxide semiconductor (CMOS) chip. In addition to storing all the various BIOS settings, the CMOS also handles the system’s real-time clock (RTC) so you don’t have to keep setting the time on every boot.

The standalone CMOS chip has long since been incorporated into the
main chipset. The information stored in CMOS is necessary for the PC to
function. If the data stored in CMOS about a piece of hardware (or about its fancier features) is different from the specs of the actual hardware, the computer
cannot access that piece of hardware (or use its fancier features). It is crucial
that this information be correct. If you change any of the previously mentioned hardware, you must update CMOS to reflect those changes.


 

 

 

* Option ROM and Device Drivers

Every piece of hardware in your computer needs some kind of programming that tells the CPU how to talk to that device. When IBM invented the PC decades ago, they couldn’t possibly have included all of the necessary BIOS routines for every conceivable piece of hardware on the system ROM chip. How could they? Most of the devices in use today didn’t exist on the first PCs. When programmers wrote the first BIOS, for example, network cards, mice, and sound cards did not exist. Early PC designers at IBM understood that they could not anticipate every new type of hardware, so they gave us a few ways to add programming other than on the BIOS. I call this BYOB— Bring Your Own BIOS. You can BYOB in two ways: option ROM and device drivers. We won't be going through this today but just keep in mind that:

option ROM way to BYOB is to put the BIOS on the hardware device itself.

And Device Drivers is a file stored on the PC’s hard drive that contains all of the
commands necessary to talk to whatever device it was written to support.

 

 

* BIOS, BIOS, Everywhere!

As you should now understand, every piece of hardware on a system must have an accompanying program that provides the CPU with the code necessary to communicate with that particular device. This code may reside on the system ROM on the motherboard, on ROM on a card, or in a device driver file on the hard drive loaded into RAM at boot. BIOS is everywhere on your system, and you need to deal with it occasionally.

 

 

* Power-On Self Test (POST)

BIOS isn’t the only program on system ROM. When the computer is turned on or reset, it initiates a special program, also stored on the system ROM chip, called the power-on self test (POST). The POST program checks out the system every time the computer boots. To perform this check, the POST sends out a command that says to all of the devices, “Check yourselves out!” All of the standard devices in the computer then run their own built-in diagnostic—the POST doesn’t specify what they must check. The quality of the diagnostic is up to the people who made that particular device.

Let’s consider the POST for a moment. Suppose some device—let’s say it’s the keyboard controller chip—runs its diagnostic and determines that it is not working properly. What can the POST do about it? Only one thing really: tell the human in front of the PC! So how does the computer tell the human? PCs convey POST information to you in two ways: beep codes and text messages. Find out more about beep codes and text messages yourself.



* Bonus Content:

1. Does your computer takes forever to start up?

Don't worry, I have a solution for you but this might have a little disadvantage. Stop turning off your PC, just put it in sleep mode. 

2. Do I have more bonus content?

NO :(

 

THANKS FOR READING :)

Post a Comment (0)
Previous Post Next Post