I've not clear what is the difference between drivers that can be "embedded" inside a monolithic kernel and drivers available only as external modules.
What kind of effort is requested to "port" some driver (provided as "external module" only) to a monolithic kernel?
I would like to be able to run Vmware Tools disabling loadable modules support and getting rid of the initrd bazaar.
Though the driver more or less remains the same(in both cases),there are definitely benefits for using "drivers" embedded in monolithic kernel.
I'll try to explain the "effort in porting" the driver part which you've asked.
Depending on the kind of driver you've, essentially you've to figure out how it will fit in the current kernel source tree, its compilation(include your .ko in the uImage) and loading of it while kernel booting. Let's illustrate each step a bit:
a.) Locate the folder (in the kernel source tree) where you think it is best suited to keep your driver code.
b.) Work on to make sure your driver code is getting compiled.[i.e ultimately it will be part of monolithic kernel image(uImage or whatever you call it)]. In this context, You've to work on your Makefile for your driver. You might have to introduce some CONFIG flags to compile your driver code. There are tons of Makefiles' and driver code lying in the source tree. Roam around and you will get a good reference of how it is being done.
c.) Make sure that your driver code is independent of any other
loadable kernel module(i.e such modules which are not part of the
"monolithic" kernel image). Because if you invoke your driver
code(which is monolithic now and is in memory) which depends on
loadable module code then it may cause some kernel
panic/segmentation fault kind of error.
d.) Make sure that your driver is registered with a higher level of
subsystem which will be initializing all the registered drivers
during boot-up time.(for example: an i2c driver once registered
with i2c driver framework will be loaded automatically when i2c subsystem is initialized during system startup). This step might not be really required if you can figure out another way of invoking your driver's __init and __exit functions.
e.) Now, Your Driver _init and (_exit sections) "should" be called
if it is getting loaded by any device driver framework or directly(i.e. while
kernel is booting up ).
f.) In case of h/w drivers, we have .probe implementation in driver
which will be invoked once the kernel finds a corresponding device.
In case of s/w drivers, I guess __init and __exit is all you have.
g.) Once it is loaded, you can use it like you were using it earlier as a loadable kernel module
h.) I'll recommend reading source code of similar device drivers in the linux kernel tree and see how they are operating.
Hope this helps.
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 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.
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.
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'm having a bit of a hard time fully understanding how the kernel starts in linux. I'm a wince developer and our company decided to run with linux instead now.
We outsourced all of the board bringup and the package I recieved is quit a bit different for the prototype board we have compared to the nitrogen6x we have been using.
Before i start listing the differences for the distro we created, the kernels are identical. The distro we have been using is a busybox system. The one we recieved from the vendor is sysvinit. I removed mdev from busybox and we are only using udev.
when I use the kernel on our busybox build the touch screen drivers breaks, or doesn' run, or does something totally magical. I'm not quit sure... there is a /dev/input/event0 device which when run on the sysvinit side is a touch device.. Is the kernel not the mechanism that binds the built-in drivers to a device node? I thought udev was for more dynamic events in the system.
On the other hand I can't really tell whats been loaded on my device. Is there a way to list running drivers that were built into the kernel? my touch pad is up? This is a fairly simple process of looking at the registry on wince to see which devices were loaded.
I guess what I'm really trying to discover, isn't so much how to add a driver to the kernel, its how the whole thing gets is plumbed together. I've found plenty of documents on createing kernel modules, but i haven't found a good resource on how to pull everything together from scratch so you can actually use said modules. Going back to the example of the touchscreen driver, its built into the kernel, how does that get plugged into /dev/input/event0??
I'm kind of having a difficult time finding good resources mostly because searching google for varations of linux/drivers/device nodes/ piles in tons of random crap from everywhere.
What you probably want to use now is evtest. It will allow you to know what are the input devices that are present and ready to use on your system.
To get more information on the input subsystem and more generic information on how the kernel is working, I can direct you to our training materials. The materials are free to download, use and redistribute.
The general answer is, there is no single, easy place to look to discover what drivers have been loaded by the kernel if they are compiled in. Of course, lsmod will display any drivers that were dynamically loaded after kernel boot.
The kernel does not create device nodes. That is, to quote your question, the kernel does not "bind" the driver to the device node. The association between kernel driver and device node is contained in the major and minor numbers registered when the driver is initialized. You can have a device node on your file system for which there is no corresponding driver (common especially in older devices where device nodes were statically created on the file system) and you can also have a driver installed for which there is no device node.
Modern Linux distros have dynamically created device nodes created on a mount point called /dev and this is usually a tmpfs file system, meaning it is volatile - it gets destroyed on every boot and recreated dynamically on each new boot.
udev is the magic that creates most device nodes based on events that it receives from the kernel when a new device is discovered (this can be after boot on device plugin, like a USB disk) or on startup when udev reads the queued events and acts on them. As you noted, busybox has a limited udev implementation called mdev.
Study udev and you will get a much better understanding of the process. Hope this helps a little.