I'm working an a system with embedded Linux (Kernel 2.6.31).
It is a AT91SAM9G20 chip inside, and some of the Pins are forwarded to the outside.
Now I want to use them as GPIO Inputs.
I read the gpio.txt documentation about using the GPIOs via filesystem, and that works very well 'til here. I connected some switches to the gpio-pins and I can see the result in /sys/class/gpio/gpioX/value. But now I'd like to react on a change without busy-waiting in a loop. (i.e echo "Switch1 was pressed").
I guess I need interrupts here, but I couldn't find out how to use them without writing my own kernel driver. I'm relatively new to Linux and C (I normally program in Java), so I'd like to handle the Interrupts via sysfs too. But my problem is, that there is no "edge"-file in my GPIO directory (I guess because this is only since Kernel version 2.6.33+). Is that right? Instead of "edge" I've got a uevent file in there, which is not described in gpio.txt.
In the gpio.txt documentation there was a Standard Kernel Driver mentioned: "gpio_keys". Is it possible to use this for my problem?
I guess it would be better to work with this driver than allowing a userspace program to manipulate kernel tasks.
I found a lot of codesnippets for writing my own driver, but I wasn't even able to find out which of the 600 gpio.h files to include, and how to refer to the library (cross compiler couldn't find the gpio.h file).
Sorry for newbie questions, I hope you could give me some advices.
Thanks in advance
See this for an example on how to do that. Basically, the thing you're missing is the usage of the select or poll system calls.
Related
Hy i wanted to Use the USART3 from my STM32MP157-DK1 Module. i wanted to write a simple driver witch listens on the RX and writes it as Kernel Log and the TX to send an a every send. To my question whats the common whay to access the uart.
What i have tried was to add the USART in the device tree so the tty driver makes it usable. But i wanted to read and write then ofer the dev/tty* file and what i know it is not recomended to open files from Kernel Space. Can someone tell me how the common way is. An example would also be helpfull. Sorry for the question but i am new in this area.
In my case i looked it up how the TTY Driver from the System does it and i do it now like this way (drivers/tty/serial/stm32-usart.c). I also found out i could use the secend CPU and share the invormations with Interrupts.
The example code can be found here:
stm32.usart.c
I know that kernel modules are used to write device drivers. You can add new system calls to the Linux kernel and use it to communicate with other devices.
I also read that ioctl is a system call used in linux to implement system calls which are not available in the kernel by default.
My question is, why wouldn't you just write a new kernel module for your device instead of using ioctl? why would ioctl b useful where kernel modules exist?
You will need to write a kernel driver in either case, but you can choose between adding a new syscall and adding a ioctl.
Let's say you want to add a feature to get the tuner settings for a video capturing device.
If you implement it as a syscall:
You can't just load a module, you need to change the kernel itself
Hundreds of drivers could each add dozens of syscalls each, kludging up the table with thousands of global functions that must be kept forever.
For the driver to have any reach, you will need to convince kernel maintainers that this burden is worthwhile.
You will need to upstream the definition into glibc, and people must upgrade before they can write programs for it
If you implement it as an ioctl:
You can build your module for an existing kernel and let users load it, without having to get kernel maintainers involved
All functions are simple per-driver constants in the applicable header file, where they can easily be added or removed
Everyone can start programming with it just by including the header
Since an ioctl is much easier, more flexible, and exactly meant for all these driver specific function calls, this is generally the preferred method.
I also read that ioctl is a system call used in linux to implement system calls which are not available in the kernel by default.
This is incorrect.
System calls are (for Linux) listed in syscalls(2) (there are hundreds of them between user space and kernel land) and ioctl(2) is one of them. Read also wikipage on ioctl and on Unix philosophy and Linux Assembler HowTo
In practice, ioctl is mostly used on device files, and used for things which are not a read(2) or a write(2) of bytes.
For example, a sound is made by writing bytes to /dev/audio, but to change the volume you'll use some ioctl. See also fcntl(2) playing a similar role.
Input/output could also happen (somehow indirectly ...) thru mmap(2) and related virtual address space system calls.
For much more, read Advanced Linux Programming and Operating Systems: Three Easy Pieces. Look into Osdev for more hints about coding your own OS.
A kernel module could implement new devices, or new ioctl, etc... See kernelnewbies for more. I tend to believe it might sometimes add a few new syscalls (but this was false in older linux kernels like 3.x ones)
Linux is mostly open source. Please download then look inside source code. See also Linux From Scratch.
IIRC, Linux kernel 1.0 did not have any kernel modules. But that was around 1995.
I am comparing a mainline Linux kernel source with a modified copy of the same source that has many drivers added. A little background: That modified source is an Android kernel source, it contains many drivers added by the vendor, SoC manufacturer, Google etc.
I am trying to identify all drivers added in the modified source that are reachable from userspace via any syscalls. I'm looking for some systematic or ideally automatic way to find all these to avoid the manual work.
For example, char device drivers are of interest, since I could perform some openat, read, write, ioctl and close syscalls on them if there is a corresponding device file. To find new character device drivers, I could first find all new files in the source tree and then grep them for struct file_operations. But besides char drivers, what else is there that I need to look for?
I know that the syscalls mentioned above do some kind of "forwarding" to the respective device driver associated with the file. But are there other syscalls that do this kind of forwarding? I think I would have to focus on all these syscalls, right?
Is there something I can grep for in source files that indicates that syscalls can lead there? How should I go about this to find all these drivers?
Update (narrowing down):
I am targeting specific devices (e.g. Huawei P20 Lite), so I know relevant architecture and hardware. But for the sake of this question, we can just assume that hardware for whatever driver is present. It doesn't really matter in my case if I invoked a driver and it reported back that no corresponding hardware is present, as long as I can invoke the driver.
I only look for the drivers directly reachable via syscalls. By directly reachable I mean drivers designed to have some syscall interface with userspace. Yes, syscalls not aimed at a certain driver may still indirectly trigger code in that driver, but these indirect effects can be neglected.
Maybe some background on my objective clarifies: I want to fuzz-test the found drivers using Syzkaller. For this, I would create descriptions of the syscalls usable to fuzz each driver that Syzkaller parses.
I'm pretty sure there is no way to do this programmatically. Any attempt to do so would hit up against a couple of problems:
The drivers that are called in a given case depend on the hardware. For example, on my laptop, the iwlwifi driver will be reachable via network syscalls, but on a server that driver won't be used.
Virtually any code loaded into the kernel is reachable from some syscall if the hardware is present. Drivers interact with hardware, which in turn either interacts with users, external devices, or networks, and all of these operations are reachable by syscalls. People don't write drivers that don't do anything.
Even drivers that aren't directly reachable by a system call can affect execution. For example, a driver for a true RNG would be able to affect execution by changing the behavior of the system PRNG, even if it weren't accessible by /dev/hwrng.
So for a generic kernel that can run on any hardware of a given architecture, it's going to be pretty hard to exclude any driver from consideration. If your hope is to trace the execution of the code by some programmatic means without actually executing it, then you're going to need to solve the halting problem.
Sorry for the bad news.
In the old days you would look at finding the base addr, DMA and IRQ to communicate with a device. I'm kinda looking for the equiviant.
I'm looking to communicate directly with an audio device, not through a driver, in Linux. Time isn't an issue, but I am struggling to find the information that I need and I know there is a possibility of needing a lot of code, that's fine.
I was wondering if anyone could point me in the right direction to achieving this.
Thankyou very much.
As far as I was aware you couldn't use IRQs or DMA if you're in a user-mode process from linux and this guide (heading 3) seems to confirm that, however after checking I managed to find this Linux driver (udmabuf) that lets you access DMA buffers through the user space; maybe this is what you are looking for?
Otherwise I would mabye try and write a similar, but more customized version of (udmabuf), specific to your purpose.
I'm not sure entirely what you are planning on using it for, but the first thing I would look for is building a driver for what you wanted to do (here's how to get started for ALSA just as an example). At least to communicate at this level, unless you wanted to do some of your own OS development? (I think this would be the way in the end if you really couldn't use drivers for whatever purpose)
I feel bad by answering this myself, WoodyDev, thankyou for pointing me in the right direction.
You are right, a driver is the best way to go.
The best solution is to read the PCI Address Space, the first 64 bytes contain all the data needed.
https://www.safaribooksonline.com/library/view/linux-device-drivers/0596000081/ch15.html
I have a piece of C code which with a chunk of memory(static array) can mimic file operations (It has APIs similar to fopen/fclose etc). So, any code that is compiled with this mimicking FileSystem can use these APIs as a FileSystem for all their needs :)
But I was wondering, if its possible somehow to register these APIs with Linux system/mouning this File system, and hence enabling any client to use this FS by using normal FileSystem calls (without any need of statically linking it with the My_FileSystem).
While searching for a solution, I came across this idea of making my_FileSystem as a Driver!!! =>
Is it possible to compile my code as a device driver (with the memory chunk in the driver) and mount this File_system # say "/mnt/MyFs", and divert FileSystem calls like USB drivers do? (If this can be done, can you please explain how its done or point me to somewhere I can read about this).
I don't want to add these as new System calls and recompile the kernel (And making life of ppl wanting to use this difficult).
This is mainly for embedded systems running Linux... But other suggestions are also welcome. :)
Thank You,
MicroKernel :)
Look at FUSE (Filesystem in Userspace), especially on examples. Its quite easy...
Take a look at tmpfs and ramfs. These already ship with Linux and do all that you're trying to do and more. I don't think either of them would be too expensive for an embedded system.
I would consider PlasticFS, but that will work reliably only if everything uses system C library (i.e. no statically linked binaries).