Study device driver source files? - linux-kernel

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!

Related

How to remove /disable the 8250.o module and implement my own 8250 driver

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

How to distinguish Windows driver from dll

I need to differ two binary files - a driver and a common dll. As far as I understand I need to view sections of this files (e.g. via DumpBin) and see if there is an INIT section. Is this criteria complete?
You need to parse the binary and look into Subsystem filed of IMAGE_OPTIONAL_HEADER, if it's NATIVE, then it's a driver. Look into the following link for details:
http://msdn.microsoft.com/en-us/library/ms809762.aspx
You would have to use heuristics to establish this fact and be certain to the extent possible. The problem is that there literally exist native user-mode programs (e.g. autochk.exe) and DLLs (frankly nothing comes to mind off hand, but I've seen them as part of native programs that do stuff before winlogon.exe gets to run) as well as kernel-mode counterparts (bootvid.dll, hal.dll and the kernel in one of its various forms ntoskrnl.exe).
So to establish it is a driver you could try the following:
IMAGE_OPTIONAL_HEADER::SubSystem, as pointed out, should signify that it's "native" (i.e. has no subsystem: IMAGE_SUBSYSTEM_NATIVE)
Verify that the IMAGE_FILE_HEADER::Characteristics is not DLL (which would mean it's a kernel or user mode DLL, check against IMAGE_FILE_DLL)
Make sure it does or does not import ntdll.dll or another user mode DLL or to the contrary that it imports one of the kernel mode modules (ntoskrnl.exe, hal.dll, bootvid.dll) to establish whether it would run in kernel or user mode.
The structs and defines are all included in winnt.h.
The gist:
establish the subsystem (only IMAGE_SUBSYSTEM_NATIVE is interesting for your case)
establish it is a DLL or not
establish whether it links against user or kernel mode components

is there a usermode ext2 filesystem library for Windows?

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.)

Creating ELF image

I need to create an ELF image file from shared objects (.so files) and write it to another partition in Windows. Then open this partition in Linux and load the shared objects.
Does anybody know how to create an ELF image (a bundle of many shared objects) in Windows?
You can use Cygwin and try a suitable GCC cross-toolchain. Perhaps you'll have to build it yourself first (which is troublesome), but there it goes...
EDIT:
Okay, here you are:
A simplified one:
Building GCC cross compiler (from "Linux" to "Windows") -- the basic steps are the same as described there. You'll just need to ./configure it with relevant --host=... and --target=.... And oh! Don't forget to set the build root, since building "in the source tree" is not supported -- you'll just get stuck in errors if you try (I did...)
A killer one:
http://cygwin.wikia.com/wiki/How_to_install_a_newer_version_of_GCC#Build_and_Install_GCC -- a complete guide.
Nowadays Linux understands NTFS. At least, it should be able to read off it.
You can also use a flash stick formatted as FAT32 or NTFS as the shared storage.
You can also run Linux in a VM and set up FTP server on it and exchange files through it.
There're many ways of sharing data between different OSes.

How to use OpenEmbedded generated images

I installed openembedded and tried building a couple of images for Zaurus SL-6000 "Tosa", basically, helloworld-image and console-image. And I ended up with an angstrom-dev/deploy/glibc/images/tosa directory that contains files like this (slightly truncated from a forum post I made elsewhere):
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa-installkit.tgz
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa.rootfs.jffs2
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa.rootfs.tar.bz2
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa.rootfs.tar.gz
helloworld-image-tosa.tar.bz2
helloworld-image-tosa.tar.gz
initramfs-kexecboot-image-tosa.cpio.gz
initramfs-kexecboot-image-tosa.jffs2
initramfs-kexecboot-image-tosa.tar.bz2
initramfs-kexecboot-image-tosa.tar.gz
modules-2.6.29-r0-tosa.tgz
updater.sh.tosa
zImage-2.6.29-r0-tosa.bin
zImage-kexecboot-2.6.24-r0-tosa.bin
zImage-kexecboot-tosa.bin
zImage-tosa.bin
I have no idea what all these do or how to install them properly. What I did try is various combinations of flashing a zImage.bin and initrd.bin using option 4 of the maintenance menu (as specified per earlier instructions). The flashing usually works alright but then when it boots, it loads a bootloader that cannot find any bootable devices. On a hunch, I tried unpacking one of the tar.gz images to an ext2 formatted SD card and tried booting with that plugged in and it was detected by the bootloader. Booting it sort of worked but it quickly exited back to the bootloader (I assume that was just a problem with the image I unpacked).
My questions are:
What is the correct usage for all of these file types, i.e. should the .jffs2 files be renamed initrd.bin and included in the flashing process? What am I supposed to do with the bz2 and gz files? Are they only for unpacking to external media?
How do I install to the internal flash? It used to work with the stable Angstrom 2007-12 build and instructions.
Is there a newer version of updater.sh (that one was not built by oe and I added it myself having picked it up from elsewhere)? The reason I ask is that when trying to flash zImage-2.6.29-r0-tosa.bin it fails during the update program with the error that the file is too big. That kernel is approximately 1.3mb while the others are 1.2mb. Is this a constraint of the SL-6000 itself? I thought it has 32mb of internal memory.
Unfortunately, none of the available documentation that I could find online talks about installing these files. I did find a small entry in the "Angstrom Manual" which talks about what they are but not how to use them as they are all device specific. Unfortunately the tosa documentation only talks about copying the files from an installkit and flashing the device from the maintenance menu.
Okay, "ant" over at OE forums was able to answer my questions ^^ Just recording the answer here for posterity.
installkit-tosa.tar.gz, contains updater.sh and zImage (the kexecboot-kernel). This kexecboot-kernel can be and is likely different from the kernel you will have on the rootfs after the machine boots. Unpack the installkit on a formatted card and follow the flashing procedure for the device.
Regarding the also be various image-rootfs.tar.gz, .bz2, and .jffs2 files. These are the root file systems that will be be booted by kexecboot. The tar.gz or .bz2 archive should be unpacked onto an ext2 (or possibly ext3) formatted SD or CF card. It will be detected by kexecboot at boot time and appear in the kexecboot menu.
If you want a rootfs in nand (installed internally), rename your-image-rootfs.jffs2 to initrd.bin and copy it on the card with updater.sh (then flash).

Resources