I'm having some trouble enabling overlayfs on my board (ROCKPRO64). It's running vanilla mainline Linux 5.9.
I have configfs and overlayfs enabled, but the device-tree directory doesn't populate in /sys/kernel/config.
My understanding is that the automatic mounting of this device-tree directory in configfs is provided by a custom patch found in board specific kernels.
In terms of mounting, I am pretty confused by the documentation in https://www.kernel.org/doc/Documentation...rlayfs.txt.
How can I manually mount this overlayfs device-tree directory to configfs to be able to dynamically load DTOs?
Not possible with a vanilla kernel.
CONFIG_OF_OVERLAY enables dynamic DT overlays, but doesn't provide the configfs interface. The author (Pantelis Antoniou) has, however, submitted the patch required (CONFIG_OF_CONFIGFS): https://lore.kernel.org/lkml/1395179766-31575-4-git-send-email-pantelis.antoniou#konsulko.com/
See also:
https://elinux.org/Frank's_Evolving_Overlay_Thoughts
Related
I want to study the source files of some of the device drivers that are installed and loaded on either a raspberry pi(raspian), beaglebone(debian) or a my laptop(ubuntu).
My aim is to learn how to properly implement my own modules by studying the source files of some drivers that actually works.
I am particularly interested in drivers that communicates with actual hardware (USB, I2C, SPI, UART etc).
Can someone tell me how to find these sources? are they available in some particular folder i.e something like /usr/src/**** or do I have to download all of the kernel source files from a particular kernel release?
All advice's, opinions and recommendations are most appreciated.
p.s I have read "Linux Kernel Development 3rd edition" but please tell me if
you know any other free/open-source books on the subject.
Best regards
Henrik
Linux Source directory and description :
arch/ -
The arch sub-directory contains all of the architecture specific kernel code.
Example :
1. 'arch/arm/' will have your board related configuration file.
like 'arch/arm/mach-omap/' will have omap specific source code.
2. 'arch/arm/config' Generates a new kernel configuration with the
default answer being used for all options. The default values
are taken from a file located in the arch/$ARCH/defconfig
file,where $ARCH refers to the specific architecture for which
the kernel is being built.
3. arch/arm/boot have kernel zImage, dtb image after compilation.
block/ -
This folder holds code for block-device drivers. Block devices are devices that accept and send data in blocks. Data blocks are chunks of data instead of a continual stream.
crypto/ -
This folder contains the source code for many encryption algorithms.
example, “sha1_generic.c” is the file that contains the code for
the sha1 encryption algorithm.
Documentation/ -
It has kernel related information in text format.
drivers/ - All of the system's device drivers live in this directory. They are further sub-divided into classes of device driver.
Example,
1. drivers/video/backlight/ has blacklight driver source which
will control display brightness.
2. drivers/video/display/ has display driver source.
3. drivers/input/ has input driver source code. like touch,
keyboard and mouse driver.
4. drivers/char/ has charter driver source code.
5. drivers/i2c/ has i2c subsystem and driver source code.
6. drivers/pci/ has pci subsytem and driver related source code.
7. drivers/bluetooth has Bluetooth driver file.
8. drivers/power has power and battery driver.
firmware/ -
The firmware folder contains code that allows the computer to read and understand signals from devices. For illustration, a webcam manages its own hardware, but the computer must understand the signals that the webcam is sending the computer.
fs/ -
All of the file system code. This is further sub-divided into directories, one per supported file system, for example vfat and ext2.
kernel/ -
The code in this folder controls the kernel itself. For instance, if a debugger needed to trace an issue, the kernel would use code that originated from source files in this folder to inform the debugger of all of the actions that the kernel performs. There is also code here for keeping track of time. In the kernel folder is a directory titled "power". Some code in this folder provide the abilities for the computer to restart, power-off, and suspend.
net/ -
net
The kernel's networking code.
lib
This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts
This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.
lib/ -
This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts/ -
This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.
mm/ -
This directory contains all of the memory management code. The architecture specific memory management code lives down in arch/*/mm/, for example arch/i386/mm/fault.c.
ipc/ -
This directory contains the kernels inter-process communications code.
**init/ -**The init folder has code that deals with the startup of the kernel (INITiation). The main.c file is the core of the kernel. This is the main source code file the connects all of the other files.
sound/ - This is where all of the sound card drivers are.
There are few more directory certs, crypto, security, include, virt and usr etc....
There are a few different methods that I use for viewing kernel related source, and I'm sure there are a few other good methods out there as well. You will find that the methods are largely the same.
Head on over to kernel.org and download the kernel of your choice. You will find driver related source under /<path to your downloaded kernel>/drivers. For example, I have downloaded and extracted kernel 4.5.5 to /usr/src/linux-4.5.5, and access the source for my drivers via /usr/src/linux-4.5.5/drivers.
Use a linux cross-reference website. Personally, I use the one hosted on free-electrons. These websites are nice for their free-text or identifier searches.
Browse Linus Torvalds' linux repo hosted on github.
Never mind, I found the source files under
~/linux/drivers/
example:
nano ~/linux/drivers/spi/spi-bitbang.c
Sorry, for any inconvenience!
I need to provide a single update file to a customer in order to update an embedded system via USB. The system is built using Yocto. I'm curious if the plan I have to implement USB updating is viable, or if I'm missing something that should be obvious.
opkg exists on the system, but in order to use opkg update it needs to have a repo to pull from. Since I have no network capabilities I will need to put the entire repo on a USB drive. Since I need to provide a single file to the customer the repo will then need to be a tar file.
Procedure
Plug USB drive in
The udev rule calls a script and pushes it to the background since this will be a long process (see this)
Un-tar the repo update file
opkg update
Notify user they may remove USB drive
At least from a high-level point of view does this sound like it is a good way to update an embedded system via USB? What pitfalls might exist?
Your use case is covered by SWUpdate - it is maybe worth to take a look at my project (github.com/sbabic/swupdate). Upgrading from USB with a single image file is one of the use case, and you can use meta-swupdate (listed on openembedded) to generate the single image with all artifacts.
Well, regarding what pitfalls might exist, one of the biggest pitfall would likely be a power outage in the middle of the process. How do you recover in that case? (The answer might depend on what type of embedded device your making). (Personally, I'm in favour of complete image based upgrades and not package based upgrades).
Regarding your scenario with the tarball, do you have enough space on your device to unpack out? It might be wiser to instead of distributing a tarball with your opkg repository, to distribute eg a ext2 or squashfs image of the repository. That would allow you to mount it from the USB drive using the loopback device.
Apart from that, as long as you have a good way to communicate work the user, your approach should work. The main issue is what do you do in case of an interrupted upgrade process. That is something you need to think about in advance.
When deciding on the update format and design there are several things to consider; including what you want to update (e.g. kernel, applications, bootloader); there is a paper on the most popular designs here: https://mender.io/user/pages/04.resources/_white-papers/Software%20Updates.pdf
In your case (no network, lots of storage available on USB) the easiest approach is probably a full rootfs update. I am involved in an open source project Mender.io which does a dual A/B rootfs update and integrates with the Yocto Project to make it easy and fast to enable updates on devices without custom low-level coding.
I would like to disable or remove 8250.c (low level UART driver) module and to implement the same with basic functionally so as it will perform read and write request from user-space
Here are my questions :
How to remove / disable the 8250.0 module
If possible give me some reference links / examples to implement the 8250 driver with basic functionality.
I am newbie for Linux device driver, excuse myself if I am wrong. I have googled a lot but didn't get the proper solution
Answer 1)
If your current system has 8250 driver built as module, just unload it:
$ lsmod | grep 8250
# rmmod 8250-driver-name
(I don't checked the exact name of the driver)
If your current system has 8250 driver built within the kernel (or you are building the Linux kernel for a new system), you must compile the kernel. You must edit your current configuration end remove the driver. You can use:
$ make xconfig
or
$ make menuconfig
for a graphic interface (run one on these commands inside the Linux kernel source).
You can also manually edit the .config file and remove the driver
CONFIG_SERIAL_8250=n
or compile it as module by setting:
CONFIG_SERIAL_8250=m
(it is not recommended for this driver, read the documentation with xconfig or menuconfig)
If you already have a working configuration file, you can copy it in your kernel source as .config
cp /path/to/you/config/file /path/to/your/kernel/source/.config
then, edit the field CONFIG_SERIAL_8250 as above.
Answer 2) The best example that I can link is the 8250.c driver. But if you want learn how to develop Linux driver, you can read Linux Device Driver
I'm hoping to find a C/C++ library that can read a number of files off an ext formatted volume from within an application in Windows. I do not need to mount this volume in a traditional way, all I need is API access to the files. Read only is fine. My one application is the only application who needs access to the volume.
In short, instead of an installable filesystem for Windows, I would prefer a library such that drivers do not need to be installed. I'm able to detect when the disk arrives, the volumes location etc.
Most important to me is the ability to read the files off the volume reliably and without the need for an installed filesystem.
I do not need write support
The ext2read project is able to read ext2, ext3 and ext4 filesystems. It achieves this entirely from user space and does not rely on a kernel driver.
It's free software (GPL) and the source code is available on GitHub. Some of the more technical aspects are also discussed at length in the project blog.
(Disclaimer: I'm not affiliated with this project in any way, but I think it can solve your problem.)
I am studying the boot process in Linux. I came across this sentence "RAM is several orders of magnitude faster than a floppy disk, so system operation is fast from a ramdisk"
The kernel will anyway load the root filesystem in RAM for executing it. So my question why do we need a ramdisk for loading the root filesystem, if the kernel loads the root file system into RAM ?
The documentation for SUSE Linux provides a good explanation of why Linux is booted with a RAMDisk:
As soon as the Linux kernel has been
booted and the root file system (/)
mounted, programs can be run and
further kernel modules can be
integrated to provide additional
functions. To mount the root file
system, certain conditions must be
met. The kernel needs the
corresponding drivers to access the
device on which the root file system
is located (especially SCSI
drivers). The kernel must also contain
the code needed to read the file
system (ext2, reiserfs, romfs, etc.).
It is also conceivable that the root
file system is already encrypted. In
this case, a password is needed to
mount the file system.
For the problem of SCSI drivers, a
number of different solutions are
possible. The kernel could contain all
imaginable drivers, but this might be
a problem because different drivers
could conflict with each other. Also,
the kernel would become very large
because of this. Another possibility
is to provide different kernels, each
one containing just one or a few SCSI
drivers. This method has the problem
that a large number of different
kernels are required, a problem then
increased by the differently optimized
kernels (Athlon optimization, SMP).
The idea of loading the SCSI driver as
a module leads to the general problem
resolved by the concept of an initial
ramdisk: running user space programs
even before the root file system is
mounted.
This prevents a potential chicken-or-egg situation where the root file system cannot be loaded until the device on which it is located can be accessed, but that device can't be accessed until the root file system has been loaded:
The initial ramdisk (also called initdisk or initrd) solves precisely the problems described above. The Linux kernel provides an option of having a small file system loaded to a RAM disk and running programs there before the actual root file system is mounted. The loading of initrd is handled by the boot loader (GRUB, LILO, etc.). Boot loaders only need BIOS routines to load data from the boot medium. If the boot loader is able to load the kernel, it can also load the initial ramdisk. Special drivers are not required.
Of course, a RAMDisk is not strictly necessary for the boot process to take place. For example, you could compile a kernel that contained all necessary hardware drivers and modules to be loaded at startup. But apparently this is too much work for most people, and the RAMDisk proved to be a simpler, more scalable solution.
The reason that most Linux distributions use a ramfs (initramfs) when booting, is because its contents can be included in the kernel file, or provided by the bootloader. They are therefore available immediately at boot, without the kernel having to load them from somewhere.
That allows the kernel to run userspace programs that e.g. configure devices, load modules, setup that nifty RAID array that contains all filesystems or even ask the user for the password to his encrypted root filesystem.
When this configuration is done, the first script that is called just exec()s /sbin/init from the (now configured and available) root filesystem.
I have seen quite a few systems where the drivers themselvess for the disk controllers and the rootfs are loaded via modules in an initramfs, rather than being included in the kernel image.
You do not strictly need an initramfs to boot - if your kernel image contains all drivers necessary to access the rootfs and you don't need any special configuration or user input (like RAID arrays or encrypted filesystems) to mount it, it is often possible to directly start /sbin/init from the rootfs.
See also:
http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
http://www.kernel.org/doc/Documentation/initrd.txt
As a side note, some systems (rescue disks, embedded and such) may use a ramfs as the root filesystem when the actual root filesystem is in a medium that may be removed or is not writable (CD, Flash MTDs etc).