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.
Related
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.
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.
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.
I am developing an embedded system on a PowerPC processor and there is need for communication with an FPGA via PCIe. I wish to use Linux/embedded-Linux as a bootloader to leverage its PCIe initialization code and driver API for simplified PCIe driver development. However in the end I want to be running bare-metal code (no OS running). So I am looking at using PetitBoot/kexec to jump from Linux to my own code.
Is this possible?
My current understanding of PCIe drivers leads me to believe that once the device is initialized, so long as I have a pointer to the address space, I should be able to simply execute MMIO R/W operations directly to the memory space. So even if kexec overwrites the driver code I should be able to use the device because the driver has done its job already.
Is this correct?
If not, what are my alternatives?
I don't think this approach would be a good idea. Drivers that were written with the Linux OS in mind are going to assume that all of the OS's resources are available, not just memory allocations. For example, it may configure interrupt handlers, but when the OS is not longer available, your hardware may get hung because nothing is acknowledging and servicing its interrupt requests.
I'm skeptical of the memory initialization as well. I suppose you could theoretically allocate some DMA memory and pass the resulting physical address to your bare-metal application as it takes over, but the whole process seems sketchy. It would be very difficult to make sure everything in Linux is shut down cleanly while leaving the PCIe subsystem running. You'll have to look at the driver's shut down routines and see what it does to the card to make sure it doesn't shut down the device and make it unresponsive to your bare-metal code.
I would suggest that you instead go through the Linux-based driver and use it as a guide to construct a new bare-metal driver. Copy the initialization code that you need, and leave out the Linux-specific configuration details.
how boot loader is different from bootstrap loader. According to me bootstrap loaders are stored in ROM and boot loaders are in hard disk in MBR (please correct me if I am wrong). bootstrap loader is the first program which get executed after startup. Now I am not getting the meaning of these sentences:-
After power on , the bootloader is controlling the board and does not rely on the linux kernel on any way.
And
The bootstrap loader acts as a glue between the bootloader and the linux kernel.
what these mean? And why we require both of them?
Bootstrap Loader
Alternatively referred to as bootstrapping, bootloader, or boot program, a bootstrap loader is a program that resides in the computer's EPROM, ROM, or other non-volatile memory. It is automatically executed by the processor when turning on the computer. (Come from WIKI)
You can think it will turn on immediately after power on, and it's part of the BIOS(BIOS has many other functions such as providing some diagnostic output, and providing a way for the user to configure the hardware)
Pay attention, in some situation Bootstrap Loader can also be called as bootloader or bootstrap...
Bootloader
Bootloader is a piece of code that runs before any operating system is running. Bootloader are used to boot other operating systems, usually each operating system has a set of bootloaders specific for it. (Come from google)
HERE IS THE STEP
0 : Power On!
1 : CPU Power On! CPU try to find something in ROM(Or ERROM)
2 : Find BIOS (or other firmware). Run BIOS
3 : BIOS(bootstrap loader and other functions) run
4 : BIOS try to find something in MBR
5 : Find MBR(512 bytes) there is some useful information of the partition
6 : Copy the MBR content into physical disk 0x7c00 where is the location of the Grub.
7 : Grub(a type of bootloader) use the information of the MBR finds a linux! Prepare to run.
8 : Run your linux!
Many architectures use a bootstrap loader or second-stage loader to load the Linux kernel image into memory. Some bootstrap loaders perform checksum verification of the kernel image, and most perform decompression and relocation of the kernel image.
The difference between a bootloader and a bootstrap loader in this context is simple:
bootloader
The bootloader controls the board upon power-up and does not rely on the Linux kernel in any way.
bootstrap loader
In contrast, the bootstrap loader's primary purpose in life is to act as the glue between a board-level bootloader and the Linux kernel. It is the bootstrap loader's responsibility to provide a proper context for the kernel to run in, as well as perform the necessary steps to decompress and relocate the kernel binary image.
Alternatively referred to as bootstrapping, boot loader, or boot program, a bootstrap loader is a program that resides in the computers EPROM, ROM, or other non-volatile memory that automatically executed by the processor when turning on the computer. The bootstrap loader reads the hard drives boot sector to continue the process of loading the computers operating system. The term boostrap comes from the old phrase "Pull yourself up by your bootstraps." The boot loader has been replaced in computers that have an Extensible Firmware Interface (EFI). The boot loader is now part of the EFI BIOS.
A bootloader, such as U-Boot or RedBoot, takes control of the hardware immediately after turn on. Boostrap loader, on the other hand, is attached to the kernel image to prepare a proper context for running kernel. For example, when compiling the kernel for an ARM architecture, the kernel file is compiled as the piggy.o file, and the boostrap loader files are misc.o, big_endian.o and head.o.