What piece of hardware executes firmware during POST?
BIOS microcontroller or CPU?
BIOS microcontroller is executing the firmware on ROM which has some configuration on CMOS (like a RAM). But during POST who is executing the firmware that is checking himself?
After POST, BIOS must "tell" CPU to assign instruction pointer to some address on memory right? that's how it jumps on startup?
There is no "BIOS microcontroller". The BIOS chip is just flash memory. All execution is done by the CPU.
When the processor comes out of reset, it begins executing from a fixed address (called the reset vector). That fixed address is mapped to the BIOS flash chip.
Once the BIOS has completed its boot time tasks (hardware initialization, POST), it begins enumerating boot devices in the order specified in the BIOS setup. The first boot device it finds with a valid boot sector, it begins executing it, and thus control of the computer is handed over to the Operating System.
One other comment, based on your comments: CMOS is just a set of registers inside the chipset that are backed by the RTC battery. They were traditionally used to store BIOS settings, but in a modern UEFI BIOS your settings are stored in flash.
Related
In my book, in the chapter where they create the CPU (chapter 7), they already assume that the instruction memory contains the instructions in machine code.
In an earlier chapter (chapter 6) this is written about start-up:
On start-up, the processor jumps to the reset vector and begins
execution boot loader code in supervisor mode. The boot loader
typically configures the memory system, initializes the stack pointer,
and reads the OS from disk; then it begins a much longer boot process
in the OS. The OS eventually will load a program, change to
unprivileged user mode, and jump to the start of the program.
But from what I understand the reset vector and the boot loader code must be in memory? Is this correct? Has my book skipped a part before the CPU jumps to the reset vector, and forgot about
how the reset vector and bootloader are loaded into memory? How does the CPU get them into memory?
All CPUs have a fixed start address. This is set in hardware (maybe you can configure it through jumpers but that's it, because the CPU has to start somewhere).
The first instructions are again set in hardware, at such fixed address, usually through a hard coded memory (like a flash). There likely is a piece of hardware that translates accesses to an address-based location to flash (NAND memory), so that means that the flash, even if it's not part of the CPU, is memory mapped.
Some processors do a memory remap, meaning that you will have those addresses accessible for other things, as you likely don't need the first stage bootloader anymore.
We can explore further by taking as an example the STM32 boot process:
Configurable boot mode though physical pins and jumpers:
This means that the CPU can start fetching instructions at startup from different locations, defined by those pins.
Factory bootloader:
The bootloader is stored in the internal boot ROM (system memory part of the flash) of any STM32 device, and is programmed by ST during
production. Its main task is to download the application program to the internal flash memory through one of the available serial peripherals, such as USART, CAN, USB, I2C, or SPI.
So this means that if the factory bootloader is selected, the CPU will start execute a program that then, by means of the selected communication protocol (USART, CAN etc..) can fetch a program from another device. This is useful if you have another processor needed to program your device once already mounted on the PCB.
Another option - Write directly to the internal flash
Another option is to select the internal flash. Since this is a persistent memory it can be programmed externally and when the CPU will start it will find, at 0x8000000, the first instruction to execute. The last section of the page that I linked explain the boot process.
I was going through the logs after booting up the intel edison. I came accross the word. Is it the name of bios?Does it do some security verification like key matching/checking and all ?
Intel Edison board, more precisely Intel Tangier SoC, has a Minute IA (i486+, also known as Pentium ISA microarchitecture) based MCU (for example, Intel Quark D2000 SoC has it as far as I know) which is part of so called Platform Services Hub (PSH). PSH has own Page Cache (to keep RTOS and its applications), LAPIC. The peripheral, such as DMA and I2C, is shared with System Controller Unit (SCU). SCU actually controls PSH.
When system starts MCU boots first. Inside it is a Viper RTOS with some modifications, i.e. it has a library to support sensors.
There is no information available from Intel regarding use of open source RTOS, such as Zephyr, on PSH.
How does a computer know where in the filesystem the bootloader is located? Is there a common file among all operating systems and all computers (maybe not all computers, but all architectures) that points to the bootloader? I know Raspberry Pi always loads bootcode.bin from the first partition of the SD card. Do PCs share a common file like this?
The Master Boot Record occupies the first 512 bytes of the first hard disk, and is the first thing loaded by the BIOS to hand over control to a program capable of booting the desired operating system. In general, a bootloader gets installed in the MBR, removing its previous content. It is (in dual boot cases) possible for them to live in co-existence, which is known as multi-booting.
It is different among different architectures. But usually there is a register the cpu reads its first instruction from after reset to begin execution. This register is often contains the bits for an assembly jump operation to another memory address which is the address of the boot code. On the next clock cycle it will fetch the operation at that address and so on.
The hardware designer will have to determine how this is implemented. For example the first instruction could be to read from a memory address on an eeprom chip that contains the boot code.
As far as PC's go the motherboard has its own boot process which will load the OS bootloader. Hence the reason you can still startup a pc and see the BIOS without an OS installed
Or at least thats what I remember from my Comp. Arch. class forever ago.
I want to access the different peripherals of i-MX6 at uboot level but I don't know how to do that?
How to add support for new devices in u-boot?
what are the differences between drivers present in u boot level and kernel level?
The five (4) boot phases.
1.ROM loads x-load (MLO)
2.X-load loads u-boot --> Primary boot-loader
3.U-boot reads commands/Load kernel --> Secondary Boot-Loader
4.Kernel reads root file system.
x-loader (Primary Boot-Loader) :
The x-loader configures the pin muxing, clocks, DDR, and serial console, so that it can access and load the second stage bootloader (u-boot) into the DDR
U-Boot (Secondary Boot-Loader) :
The u-boot can perform CPU dependent and board dependent initialization and configuration not done in the x-loader. The u-boot also includes fastboot functionality for partitioning and flashing the eMMC. The u-boot runs on the Master CPU (CPU ID 0), which is responsible for the initialization and booting; at the same time, the Slave CPU (CPU ID 1) is held in the “wait for event” state.
U-Boot is kind of firmware. It'll basically initialize basic functionality. Like Display, CPU0, FastBoot functionality, Create a temporary file system for loading a kernel and Loading Kernel.
Kernel Driver :
A device driver is a program that controls a particular type of device that is attached to your computer. There are device drivers for printers, displays,Touch, CD-ROM readers, diskette drives, and so on.
U-Boot is mainly for loading a Operating System (Kernel). Device Driver is part of kernel for controlling a device. you want to accesses your device in u-boot loader then you will have to initialize all need hardware for your device like memory an all.
For instance, how does it know that all addresses between:
0xXXXXXX and 0xYYYYYY
map to the RAM / Graphics Card / Monitor / etc...
on the motherboard?
It does not know exactly everything you listed.
What's the key to all this is that a CPU never goes alone inside a silicon chip. There are indeed a lot of specialized hardware circuits called peripherals that compose every processor.
What it does know then, is the location on its memory space of every peripheral internal to the chip/SoC. For obvious reasons, as it is wired that way by the chip designer (Intel, Freescale, AMD, ...)
By extension, the external RAM being controlled by an internal peripheral (the DRAM controller), it does also know the address of the external DRAM.
Same goes for the external peripherals on a PCIe bus, as they are driven by a PCIe controller. And so on.
However, the processor itself does not know what's on the PCIe bus, that's the job of the drivers and the operating system to have the awareness of all this. A lot of our computer stuffs are wired on a PCIe bus at some point. Through a companion chip, or directly, ... To identify precisely what's present on this bus, and what driver to load for each of these peripheral, there's a handshake of identifiers exchanged between the OS and the peripherals. So that the OS can know at what address resides the GPU, the USB bus, the SATA bus, etc.