I am new to embedded Linux development. I have to port uboot and custom Linux distribution to a new ARM based board.
The uboot we are using (2009.08) does not have Arch and DTS folders. I suppose it is an older version which does not use use DTS to pass hardware information to the Kernel (v 3.0). I have read a lot about DTS but here is not enough information on internet about this (obsolete?) method of passing hardware information from uboot to kernel that we are using. Internet tells me that there are C files for this task both in uboot and kernel source code that have to be sync'd, but can some one point me in that direction? Also, please correct me if my assumptions are wrong, and ask for more info if needed.
The (old) method to pass data between U-Boot and the Linux ARM kernel is called the ATAG memory list. Information such as usable memory regions, machine type and board information are passed from U-Boot to the Linux ARM kernel using this data list.
In U-Boot, ATAGs are built in lib_arm/armlinux.c (1.1.5) or lib_arm/bootm.c (2009.08) or arch/arm/lib/bootm.c (2015.04), and require the configuration options CONFIG_SETUP_MEMORY_TAGS and salient CONFIG_xxx_TAG s.
Then the ATAGs are processed by Linux in arch/arm/kernel/setup.c.
For documentation see Section 8 of this or this alt site.
Addendum
Also see slide #4 of this presentation about before-Device_Tree booting
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'm reading the book and it tells that:
After U-Boot loads Linux kernel, the kernel will claim all the resources of U-Boot
What does this mean? Does it mean that all data structures that allocated in U-Boot will be discarded?
For example: during U-Boot, PCIE and Network Device will be initialized.
After booting Linux kernel, will the PCIE and Network Device data structure be discarded? Will the Linux kernel do PCIE and NEtwork initialize again? Or U-Boot will transfer some data to kernel?
It depends on your CPU architecture how the communication happens, but it is usually via a special place in RAM, flash or the filesystem. No data structures are transferred, they would be meaningless to the kernel and the memory space will be different between the two. Uboot generally passes boot parameters like what type of hardware is present, what memory to use for something, or which type of mode to use for a specific driver. So yes, the kernel will re-initialize the hardware. The exception may be some of the low level CPU specifics which the kernel may expect uboot or a BIOS to have setup already.
Depending on your architecture, there may be different mechanism for the u-boot to communicate with the Linux kernel.
Actually there may be some structures defined by u-boot which are transferred to and used by the kernel using ATAGS. The address in which these structure are passed is stored in r2 register on ARM. They convey information such as available RAM size and location, kernel command line, ...
Note that on some architectures (like ARM again) we have support for device-tree which intends for defining the hardware in which the kernel is going to be run as well as kernel command line, memory and other thins. Such description is usually created during kernel compile time, loaded into the memory by the u-boot and in case of ARM architecture, its address is transferred through r2 register.
The interesting thing about this (regarding your question) is that u-boot can change this device-tree structure before passing it to the kernel through device tree overlay mechanism. So this is a (relatively) new way of u-boot/kernel communication. Note that device-tree is not supported on some architectures.
And at the end, yes, the hardware is reinitialized by the kernel even in they have already initialized by the u-boot except for memory controller and some other very low level initialization, AFAIK.
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.
We have built a simple instruction set simulator for the sparc v8 processor. The model consists of a v8 processor, a main memory and a character input and a character output device. Currently I am able to run simple user-level programs on this simulator which are built using a cross compiler and placed in the modeled main memory directly.
I am trying to get a linux kernel to run on this simulator by building a simplest bootloader. (I'm considering uClinux which is made for mmu-less systems). The uncompressed kernel and the filesystem are both assumed to be present in the main memory itself, and all that my bootloader has to do is pass the relevant information to the kernel and make a jump to the start of the kernel code. I have no experience in OS development or porting linux.
I have the following questions :
What is this bare minimum information that a bootloader has to supply to the kernel ?
How to pass this information?
How to point the kernel to use my custom input/output devices?
There is some documentation available for porting linux to ARM boards, and from this documentation, it seems that the bootloader passes information about the size of RAM etc
via a data structure called ATAGS. How is it done in the case of a Sparc processor? I could not find much documentation for Sparc on the internet. There exists a linux bootloader for the Leon3 implementation of Sparc v8, but I could not find the specific information I was looking for in its code.
I will be grateful for any links that explain the bare minimum information to be passed to a kernel and how to pass it.
Thanks,
-neha
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.