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.
Running code exclusively in ROM has some security benefits and I was wondering if anything in the Linux kernel requires the ability to run code in RAM.
No it is not directly possible.
But you can start a normal process and then map some ROM ranges into the process space (maybe via device driver depending how the ROM is mapped) and then run code in this mapped range.
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.
I am having issues in loading my root fs and after inspecting the Kernel Log it says some thing like
"INITRD: 0x1f8ca000+0x0028ac63 is not a memory region - disabling initrd"
What does this mean?
Background
I am running linux on one core of an ARM Cortex A9 and trying to run another baremetal application on another core. I have changed the device tree to reflect this and i am reserving part of the SDRAM for Linux and part for the bare-metal application. I am using Uboot. Is this something to do with the uboot?
Cheers,
S
As you are NOT dedicating the entire RAM to the Linux kernel on the main core, you will need to ensure that the intrd load address specified in the bootargs is accesible from the main core.
Next, this info is usually passed to the Linux kernel in bootargs passed from u-boot as
initrd=<initrd-start-addr>,<initrd-size>
Modify it according to your custom memory-map
Finally in u-boot, load the initrd at the new proper address you just specified and boot the Linux kernel.
I am new to bootloader and Linux kernel. I have been working on a project where we have to replace booting QNX kernel with Linux kernel .Our current bootloader code has a support for booting QNX kernel.It seems like bootloader also has support for booting Linux(NOT sure) and I need to know is it doing enough to boot Linux Kernel.
Below is what our Bootloader is doing.
Bootloader is calling start_kernel function which have two argument passed to it one is kernel entry point and second is pointer to boot line
1.Address 0X90000ULL which is type casted to boot_params structure.
2.Relocate initrd
3.Copy boot sector ,Set up data and commad line to final resting place
4.Initialize Linux GDT
5.Jump to Kernel entry point
6.Disable interrupt
7.Lunch_kernel()
Now in above code two tricky things which doubted support for Linux kernel booting.
The first thing is the way Jump to kernel entry point, normally I see jumping to kernel entry in uboot or Linux source is in assembly but in our bootloader it simply filing a structure .
struct
{
long Kery;
long kernel_code_segment;
}
jumpv;
void *jump_s;
jumpv.kery=first argument pass to start_kernel;
jumpv.kernel_code_segment=0x10;
jump_s=(void *)&jumpv;
Second thing is the Lunch_kernel() for which definition is not present at all in code base.
Now is above stuff enough to pass control to Linux image or what else I can add/modified to boot the Linux image in our current bootloader code.
We are on working X86 architecture.
Due to some reason we can't do hit and trial on our board until we are sure about things.