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.
Related
I'm trying to understand how U-boot PSCI interface is used to boot kernel into HYP mode.
Going through u-boot source, I do see there is a generic psci.S and other psci.S which is board specific and have following doubts.
1). How and where psci.S fits in normal u-boot flow(when and how psci service like cpu_on and cpu_off is called while booting u-boot).s
2). How this psci interface of u-boot is used to boot kernel in HYP mode(what is it in psci interface that allow Linux kernel to booted in HYP mode)?
1). How and where psci.S fits in normal u-boot flow
U-boot sets aside some secure-world memory and copies that secure monitor code there, so that it can stay resident after U-Boot exits and provide minimal handling of some PSCI SMC calls.
(when and how psci service like cpu_on and cpu_off is called while booting u-boot)
They aren't. U-Boot runs and hands over to Linux on the primary CPU only. Linux may bring up secondary cores later in its own boot process, but U-Boot is long gone by then, except for the aforementioned secure monitor code.
2). How this psci interface of u-boot is used to boot kernel in HYP mode
It isn't.
(what is it in psci interface that allow Linux kernel to booted in HYP mode)?
Nothing.
The point behind the patch series you refer to is that it was (and unfortunately still is) all too common for 32-bit ARM platforms to have TrustZone-aware hardware designs but crap software support. The vendor BSPs implement just enough bootloader to get the thing started, and never switch out of secure SVC mode from boot, so the whole of Linux runs in the secure world, and their kernel is full of highly platform-specific code poking secure-only hardware like the power controller directly. This poses a problem if you want to use virtualisation (which, if you're the KVM/ARM co-maintainer and have recently bought yourself a CubieTruck, is obviously a pressing concern...) - it's easy enough to take the U-boot code for such a platform and make it switch into NS-HYP before starting Linux, thus enabling KVM (upstream U-boot already had some rudimentary support for this at the time), but once you've dropped out of the secure world you can't then later bring up your secondary CPUs with the original smp_operations that depend on touching secure-only hardware.
By implementing some trivial runtime "firmware" hanging off the back of the bootloader, you then have the simplest way of calling back into the secure world as needed, and it makes the most sense to move the necessary platform-specific code there to abstract the operations away behind a simple firmware call interface, especially if there's already a suitable one supported by Linux.
There's absolutely nothing special about PSCI itself - there are plenty of ARM platforms that have proper secure firmware, with which they implement power management and SMP operations, but via their own proprietary protocol. The only vaguely relevant aspect is that conforming to the PSCI spec guarantees that the all CPUs are going to come up in the same mode, thus if you did initially enter Linux in HYP, you won't see mismatched secondaries coming up in some other incompatible mode or security state.
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 am trying to understand how a kernel boots. I am currently trying to port a new kernel to hTC Incredible S VIVO (s710e) device, but I cannot get it to boot. So, I looked into the device's original kernel, and looked through some documentation, and found out that the device uses ATAGs. Now, I have several questions that I cannot find a clear answer for:
What are ATAGs?
What are they used for?
How does the kernel boot using ATAGs?
Do ATAGs play a vital role in booting a kernel?
ATAGS are ARM tags. They are used to carry information such as memory size from boot code to kernel. Some references (which in turn lead to other references): booting standards, customized ATAG.
This reference arm/Booting explains theory, but does not much tell a user what to do.
On my target I use the following in my U-Boot config: CONFIG_CMDLINE_TAG, CONFIG_SETUP_MEMORY_TAGS, and these in my kernel config: CONFIG_ATAGS=y, CONFIG_USE_OF is not set. Not sure if that is sufficient for you but it gives you clues to search on, good luck.
ATAGS are not only arm-related, at all. Look into other archs head.S. They are special parameters to be passed to the kernel through some registers and pointers.
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 linux kernel and Try to understand booting of Linux kernel from the point it loaded into RAM,I would like to know after Linux image loaded into RAM ,How control is passed to this image ,what all are necessary parameter needs to pass to kernel and can we pass control to linux image without passing any parameter,
I am looking into the UBOOT code with "bootm.c" but unable to understand where control is passed to Linux image,which function is responsible for it.
Is load_zimage() is responsible for passing the control/
Can anybody lead me to right direction or suggest some good tutorials on this particular part
of linux booting from x86 archetectiure.
I think it depends. Different kinds of CPU architecture, they use different ways to pass information to Linux Kernel. Of course, the Linux Kernel can boot up successfully without bootloader pass information to it, but it need to statically set up correctly in the Linux Kernel, such as root device name, console device, mem size, and also some parameters to enable/disable some features in Linux Kernel.
Why bootloader need to pass various information(parameters) to Linux Kernel, I think it's flexible consideration. Think about this case that it's possible to share one Linux Kernel on two board with same CPU but different peripheral modules.
Let me show some examples that UBoot passes information to Linux Kernel:
(1) For PowerPC cpu, nowadays they use DTB(Device Tree Blob) file to pass more information from UBoot to Linux Kernel. They consider UBoot and DTB as firmware, and in Linux Kernel, they adopt one open firmware(OF) infrastructure. You may know "bootm" command in UBoot, bootm can have three parameters, the first is uImage address, the secondary one is initrd address, and the third one is the dtb address.
(2) Earlier days, they use bootargs to pass information to Linux Kernel. Also you may know there is gd/bd structure in the UBoot, they also can pass information to Linux Kernel. But the information passed in this way is limited, not like DTB.
Hope the above information help you to understand your question.