Linux Device Drivers 4th Edition
Charise Scrivner
I would like to learn how to write device drivers because I think it would be fun. I use a Mac OS X Macbook, but I also have an Ubuntu machine (running on a Mac Min). I am pretty familiar with C and currently am reading this book. I have found some links online such as Mac Dev Center. I am doing this because it would be fun. I think there would be real gratification to see hardware operate because of software I wrote.
I guess what I would like is some tips or advice and guidance, and does anyone know of a list of devices that don't have drivers or can I write a driver for something that's already supported (would prefer the former so I'm actually providing value). What's a good device to get started with? Am I biting off more than I can chew? I'm not afraid of low level programming or assembly or whatever amount of effort is required. I'd like a challenge really!
Writing a device driver can be pretty simple, or it can be almost arbitrarily complicated. For instance, I've been involved in a project where it took six of us almost three years to solve ONE bug in a device driver. Of course, we cleared out dozens of other bugs while looking for it... the code improved immensely. The fix turned out to be an eight line patch, that cost, conservatively, about a million dollars.
For Mac you might want to take a look at Mac OS X Internals book. It's think and heavy but fun to read. It is mostly about PowerPC-based Macs but has an appendix about Intel-based ones. For Linux take a look at Linux Device Drivers, 3rd Edition - it's lighter (free PDFs online :) and is really device driver-oriented, might be a better start.
I was introduced to Linux Device DriversBook by Alessandro Rubini, Greg Kroah-Hartman, and Jonathan Corbet in a video by LiveOverflow from 2020.But I never got around to reading it.This post is just me jotting down my experiences going through this book.
I built the kernel with the existing config from my Arch Linux install a couple of years back. And custom kernels forbuilding TWRP and some test ROMs for my previous android devices. But that was it. The kernel source is too scary for me ?
So, in other words, this is another attempt to try and understand the kernel source, or at least some parts of it.Heard, device drivers are a good starting point? Well, the kernel can be thought of as a driver.
I jumped on Vagrant to set up a temporary, quick VM. Just followed theVagrant ArchWiki and used libvirtas the virtualization provider. Also had to install nfs-utils along with the libvirt dependencies.
Copied over the hello.c file from here to /vagrant/src directory on the guest (or to ./src directory on the host)and added the makefile. Make sure to removeall the modules that we are not building at this step -> Only keep hello.o in obj-m.
Porting Linux device drivers to target more recent and older Linux kernel versions to compensate for the everchanging kernel interface is a continual problem for Linux device driver developers. Acquiring information about interface changes is a necessary, but tedious and error prone, part of this task. In this paper, we propose two tools, Prequel and gcc-reduce, to help the developer collect the needed information. Prequel provides language support for querying git commit histories, while gcc-reduce translates error messages produced by compiling a driver with a target kernel into appropriate Prequel queries. We have used our approach in porting 33 device driver files over up to 3 years of Linux kernel history, amounting to hundreds of thousands of commits. In these experiments, for 3/4 of the porting issues, our approach highlighted commits that enabled solving the porting task. For many porting issues, our approach retrieves relevant commits in 30 seconds or less.
USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and open to everyone. Support USENIX and our commitment to Open Access.
There are times when working with virtual hardware and not real hardware feels very liberating and efficient (not to mention safe). Bringing up, modifying, and extending operating systems is one obvious such case. Recently, I have been preparing an open-source-based demonstration and education systems based on embedded PowerPC machines, and teaching myself how to do Linux device drivers in the process. This really brought out the best in virtual platform use.
First of all, it was dead easy to test a new version of the driver: start the simulation from a checkpoint of a booted and configured machine, load the driver into the target file-system using the Simicsfs backdoor (similar to the VmWare hostfs solution), and then insmod it. This was automated in a script that typed the needed commands on the target-command line with no manual intervention. Each iteration takes a few seconds, which is just as fast an convenient as testing a simple program directly on the host.
Diagnosing what went wrong was greatly facilitated by the simulator: did the driver access the device I had prepared for it? Were values read as expected? Obviously, there were a lot of such cases, I am not the most expert device driver programmer (yet).
To sum things up, so far, I have learnt quite a lot about doing Linux device drivers and how to setup hardware in a Linux system, and I think it would have been much harder to learn and experiment like I have done had I been stuck with physical hardware (not to mention the plain impossiblity of just inserting a new piece of hardware in a simple way into a physical system).
Adding new sysfs files is now easy to do by adding them to the _entries array and adding a show and/or set function to implement it. This works for all common and simple cases. If you need to sleep on the sysfs file, I think you might need to use the lower-level interfaces.
This is a Linux industrial I/O (IIO) subsystem driver, targeting RF Transceivers.The industrial I/O subsystem provides a unified framework for drivers for many different types of converters and sensors using a number of different physical interfaces (i2c, spi, etc).See IIO for more information.
Each and every IIO device, typically a hardware chip, has a device folder under /sys/bus/iio/devices/iio:deviceX.Where X is the IIO index of the device. Under every of these directory folders reside a set of files, depending on the characteristics and features of the hardware device in question. These files are consistently generalized and documented in the IIO ABI documentation. In order to determine which IIO deviceX corresponds to which hardware device, the user can read the name file /sys/bus/iio/devices/iio:deviceX/name. In case the sequence in which the iio device drivers are loaded/registered is constant, the numbering is constant and may be known in advance.
Because of differences in silicon implementation; and the way an IIO device wants to be expressed as a device with channels and attributes, there may be specific attributes that are exposed on multiple channels, that control the same bit/register in the device (are duplicated for convenience or to match the IIO model). A specific example of this is:
The AD9361 transceiver contains two identical RFPLL synthesizers to generate the required LO signals.One is programmed for the RX channel and the other for the TX channel.The tuning range supported by this driver covers 70MHz to 6GHz (AD9363: 325-3800 MHz) with 2Hz tuning granularity.
If both, the TX and RX Local Oscillators (LO) are set to the same frequency or very close to each other.The TX LO may leak into the RX path. Usually this is avoided in TDD mode, since always only one of the LOs is enabled at a given time. However sometimes it can be beneficial in FDD mode to turn the TX LO off. Care must be taken since TX LO in Power-down mode, will cause the TX QUAD calibration to fail.
The driver allows switching between external and internal LO on the fly.Writing 1 into out_altvoltage0_RX_LO_external/out_altvoltage1_TX_LO_external switches to external LO.Respectively writing 0 switches back to the internal synthesizer.
When in fastlock pin select mode (adi,[txrx]-fastlock-pincontrol-enable).This file needs to be written once with a value, before the pin-control can be used.This will moves the device into fastlock mode.
The AD9361 RX signal path passes downconverted signals (I and Q) to the baseband receiver section. The baseband RX signal path is composed of two programmable analog low-pass filters, a 12-bit ADC, and four stages of digital decimating filters. Each of the four decimating filters can be bypassed. The corner frequency for each low-pass filter is programmable via SPI registers. Figure below shows a block diagram for the AD9361 RX signal path. Note that both the I and Q paths are schematically identical to each other.
The high level in_voltage_sampling_frequency attribute effectively controls the BBPLL frequency the ADC Sample clock and all following decimating filter blocks except the FIR block which is handled upon user configuration.This IIO device attribute allows the user to control the Baseband (BB) Sample Rate in Hz granularity in the range from 521KSPS up to 61.44MSPS, also depending on the FIR filter decimation chosen.in_voltage_sampling_frequency as well as out_voltage_sampling_frequency are not entirely independent, by default the both need to match unless adi,fdd-rx-rate-2tx-enable is enabled.Then RX rate can be twice the TX rate.
The high level out_voltage_sampling_frequency attribute effectively controls the BBPLL frequency the ADC Sample clock, the DAC clock and all following interpolation filter blocks except the FIR block which is handled upon user configuration.This IIO device attribute allows the user to control the Baseband (BB) Sample Rate in Hz granularity in the range from 218KSPS up to 61.44MSPS, also depending on the FIR filter decimation chosen.out_voltage_sampling_frequency as well as in_voltage_sampling_frequency are not entirely independent, by default the both need to match unless adi,fdd-rx-rate-2tx-enable is set.Then RX rate can be twice the TX rate, however this mode needs to be supported by the FPGA/Baseband-Processor.The feedback clock must be externally divided.
4a15465005