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.
Related
Once the Uboot loads the Linux kernel image (ZImage) onto the ram, it invokes it (could be using bootz, bootm or some other commands based on the type of the kernel Image) and then the control goes to booting the kernel. Does the uboot will be informed about the kernel boot result?, means, whether the kernel booting went through completely or got stuck in the middle because of errors?.
I looked at do_bootz, do_bootm_states and boot_selected_os api's in the uboot src code to see if there is any way to know about the final kernel boot result, but I couldn't able to figured it out.
Details:
U-boot Version: 2017.03-rc2
api's are available at: cmd/bootz.c and bootm.c files.
If any one in this community knows about it or have an idea about it, please explain to me or point me to the correct path.
Thanks in advance.
Regards
Vamsi Chagari
After bootm, booti, bootz transfer control to the kernel the memory formerly used by U-Boot will be reused by the operating system. As U-Boot is no longer in memory it cannot be informed about the operating system status.
If you use the bootefi command the U-Boot implementation of the UEFI runtime services stays in memory while the operating system is starting. The UEFI services can be called by the operating system. These include services relating to variables. One use of UEFI variables is the definition of the boot sequence.
Unfortunately UEFI variables are not yet completetly implemented in U-Boot (as of version v2018.07). They currently cannot be accessed after exiting boot services.
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'm playing a little bit with the kernel linux and I got some errors during the boot process : Kernel panic - not syncing: Attempted to kill init!
I want to understand how the boot process of the linux kernel works in general, and especially during and after the start_kernel() function and the load of the rootfs.
Thank you guys.
Lets take an example of porting linux on beaglebone through mmc.,
You get the idea of boot process. It works like this -
First when we power on the board the bootrom code executes(Hard coded in the rom of board) and initialize the CPU, disable MMU.
after executing boot-ROM code it jumps to MLO (X-loader with header, it is board specific) and load it.
MLO executes and load the Uboot it is board specific and all peripherals are initialized here.
Now the Uboot executed and looking for bootcmd where the Kernel and rootfs addressed(in mmc). this calls the kernel
Kernel extracted and than it calls the initramfs (root file system)
Actually user can not interact with hardware by Kernel only thus the rootfs gives user inerface to the kernel to run application.
I just compiled the U-Boot bootloader and I see a few file names in the u-boot program directory which are:
u-boot.bin
u-boot.img
u-boot.lds
u-boot.srec
Basically, I'm interested in the files with extensions .img and .bin. What is different between them?
Is u-boot.img for SD card and u-boot.bin for flashing to NAND ?
u-boot.bin is the binary compiled U-Boot bootloader.
u-boot.img contains u-boot.bin along with an additional header to be used by the boot ROM to determine how and where to load and execute U-Boot.
The way in which these files are deployed can depend upon the nature of your device, its boot ROM and where the files are loaded from.
Boot ROMs are generally provided by the SoC/CPU vendor. These days, many boot ROMs are capable of loading u-boot.img, reading the file's header, loading u-boot.bin into memory and finally executing it. Some boot ROMs are complex enough to load u-boot.bin directly or even the OS kernel. While others may load an intermediate bootloader (MLO/X-Loader) first which then takes responsibility for loading U-Boot as the secondary bootloader once external memory is initialized.
This image depicts the latter case as implemented by some TI OMAP processors:
This boot process is reduced by some devices by moving many of the X-Loader tasks into U-Boot and placing boot parameters (such as memory addresses) into the header of u-boot.img avoiding the need for an intermediate bootloader.
You will need to investigate the properties of your device to determine how you should go about deploying U-Boot.
So I am on the quest of learning embedded Linux and have a few questions that I cannot seem to find an answer for.
1) Does the kernel depend on the dtb/dts files when compiling? I thought that the kernel only needs to know the chip architecture (i.e. arm) and the dtb file is loaded by the boot loader (uBoot) so therefore the kernel only needs to load its drivers which are configured by the dtb file.
2) Mixing and matching: I'm under the impression that I can mix and match any combination of boot loader, dtb, kernel, rootfs, and modules given the following
kernel: must know which chip it is compiled for
dtb: must know the board details and chip, i.e. how much ram, configure a GPIO for SPI
boot loader: must know the chip and uEnv.txt must have params for the kernel and dtb location
rootfs: completely independent
modules: must be compiled with the specific version of kernel
3) Drivers: If I want to load a SPI driver do I need anything specific or will the kernel know how to operate this because the dtb file setup the required registers?
4) Modules: Are these just dependent on the kernel or do they need to know something about the chip and board (when I say chip what I mean is do they have to know more than a simple arm or x86 architecture)?
Thank you in advance, I know these are some basic questions but any help is appreciated.
1) Does the kernel depend on the dtb/dts files when compiling? I thought that the kernel only needs to know the chip architecture (i.e. arm) and the dtb file is loaded by the boot loader (uBoot [sic]) so therefore the kernel only needs to load its drivers which are configured by the dtb file.
The Linux kernel is compiled without any dependency on the Device Tree.
The compilation of the kernel does depend on the chip architecture, but which code modules that are compiled depends on the board configuration(s) and feature selection.
BTW it's U-Boot for Universal Boot, not microBoot.
2) Mixing and matching: I'm under the impression that I can mix and match any combination of boot loader, dtb, kernel, rootfs, and modules given the following
kernel: must know which chip it is compiled for
dtb: must know the board details and chip, i.e. how much ram, configure a GPIO for SPI
boot loader: must know the chip and uEnv.txt must have params for the kernel and dtb location
rootfs: completely independent
modules: must be compiled with the specific version of kernel
Essentially correct, but typically one doesn't go overboard in trying to "mix-n-match". There are often optimal or preferred (or at least appropriate) choices.
By "rootfs" I'm assuming you mean type of filesystem for the rootfs, rather some image of a rootfs. (See Addendum below.)
3) Drivers: If I want to load a SPI driver do I need anything specific or
There are two types of "SPI driver", the master and protocol.
The SPI master driver is for the SPI controller chip that serves as the one interface master. This is usually a platform driver and not have a device node in /dev.
For each SPI slave device there must be a protocol driver. This driver will typically have a device node in /dev.
will the kernel know how to operate this because the dtb file setup the required registers?
The Device Tree must specify which driver is for which device and any/all resources allocated/assigned to each device.
The dtb file does not "setup" anything. It's only configuration data; there is no executable code. A device driver, typically during its probe or initialization phase, is responsible for acquiring/allocating its resources.
4) Modules: Are these just dependent on the kernel or do they need to know something about the chip and board?
Your use of "modules" is ambiguous. Source code files are sometimes referred to as "modules". Presumably you really mean loadable kernel modules.
Although most people associate kernel modules (only) with device drivers, other kernel services such as filesystems and network protocol handlers can also be built as modules.
The primary rationale for a kernel module versus static linkage (i.e. built in the kernel) is for runtime configurability (which in turn improves memory efficiency). Optional features, services and drivers can be left out of the kernel that is booted, but can still be loaded later when needed.
Loadable modules are "dependent" on the kernel simply because of linking requirements for proper execution. The degree of "chip and board knowledge" obviously depends on the functionality of the module, just like any other piece of kernel code.
Addendum
when I say rootfs I am referring to a prebuilt rootfs
A kernel image and (prebuilt) rootfs image are not "completely independent".
The executable binaries and the shared libraries in the rootfs image must be compatible with the kernel features. More significantly, since kernel loadable modules are installed in the rootfs and not with the kernel image, and these modules can be strictly tied to a specific build of a kernel version, it makes sense to pair a kernel image with a rootfs image.