I am programming Linux kernel module for communication with device connected through UART, but I don't know how to access UART from kernel module. I don't want to write my own UART driver, I would like to use the existing one and only add communication layer for my device. I saw something similiar done in userspace-like manner, however I read that kernel modules should not access files like that. I am wondering if it could be done using existing driver's structs and functions, because that's how I have already programmed module, which used I2C. Example of a module reading from UART would be very useful.
Related
I like to ask: do applications like Apache Webserver on Linux, Wireshark, and software like network tools and other real world applications that have to do work with network connection, do they need kernel module, If no then is it to what extent a normal practice that applications do have kernel module. Like when I install some application then kernel module installs with it. I know when I enable IIS server from windows, specific kernel module do get enabled that does IIS work. (don't know why that OS does not implement raw sockets api so developer can use)
My question: Some time ago I was trying to make tcp server using raw socket and found that it was something not that easy since kernel does all sorts of things like (correct me if I am wrong)
Checking for spoofed packets
adding its own headers info inside packets
So I am about to Make an application that does following things in kernel
Configuring NIC card like reading card registers and reporting back
shutting down Network Interface
Starting Network interface
Reading packets from DMA RX and reporting average number of packets received to detect DOS attacks and if detects DOS then shutting down specific Interface/ like reporting counter for packets
And the Application will just act as a command controller. Like a user can use the application to make changes specified in above 4 points.
So I like to ask you is it common practice for applications to have a kernel module and why this is a resorted option if someone like to choose embedded kernel module in applications,
Above things are for learning purposes.
No. Linux programs very rarely have kernel modules. Kernel modules are normally for hardware device drivers.
If a program does need a certain kernel module, it will tell you to install the module yourself. It won't include a copy of the module.
It sounds like you want to make your own driver that replaces the normal driver for your network card. It's possible, but nobody does it. If you want to shut down or start up a network interface, there is already a way to do that without writing your own kernel module. If you want to count the packets, there's already a way to do that. If you want to see all the packets, there's already a way to do that.
There's no way to read card registers already - that's because every card has different registers. But whatever you want to do with those registers, there's probably a way to do it already.
I've been tasked to import the spi driver into an existing platform running Openwrt.
After "successfully" build the full Openwrt: packages and the kernel matching the one running into the platform, including the spidev kernel module I run into some trouble in make this module work.
**insmod** of the driver terminates without error, and I see that in the **/sys/class** the creation of the directory **spidev**, but it is empty.
Looking at the code of the spidev kernel module, the function **probe** has caught my eye. My feel is that this function is what actually allocates the minor device number an make the device available to be used. But it's not clear to me who, or what should call it.
Another doubt I have is about the architecture. The spi depends on the underlaying architecture, which in my case is the MT7620 soc which is a mipsel architecture have a specific spi code. In my understanding this SOC specific code is wrapped by the spidev kernel module and the link between these two entities should be
status = spi_register_driver(&spidev_spi_driver);
in the
static int __init spidev_init(void)
function.
Again, I'm far to be sure of what I'm writing and I'm here asking for directions.
First, you may want to read the Linux Device Driver - Chapter 14.
Generally speaking, in the Linux kernel you have devices and drivers on a bus (subsystem). You have to register them using the functions register_device() and register_driver() (the exact name depends on the subsystem). When a device or a driver get registered the subsystem will try to match devices with drivers. If they match, the subsystem calls the driver's function probe(). So, the execution of the probe() function can be triggered by the driver registration or the device registration. This also means that the device exists before the execution of probe()
Back to your specific case: SPI. To register a device instance you need to use spi_alloc_device and spi_add_device, or spi_new_device. Where to put this code? This depends on your need. Typically, the SPI devices are declared in some architecture file or device-tree description. Probably you can also do it in a module (not sure).
The spidev is a Linux device driver that exports the SPI raw interface to the user-space. This means that once you register an SPI device instance the driver spidev take control of it. Actually, the spidev does nothing: it waits for an user-space program to read/write data on the SPI bus. So, you will end up writing the driver for your device in userspace.
I have a Linux driver for an external MCU application. The driver and the MCU communicate over a bus using our own protocol.
I would like to share the program code for the protocol features between the kernel module and the MCU but since it's not possible to build a lib for the kernel my only idea so far is to write the code "as kernel as possible" and then just copy the entire .c file between the platforms.
Are there any other ways? Surly I can't be the first to want to do this.
I'm talking about code reuse, not IPC mechanisms.
Thanks!
It requires some hardware abstraction so the code implementing the protocol needs to be generic as possible not requiring any hardware specific details.
The file implementing the protocol could have functions like init, exit, read, write and interrupt. The hardware implementation itself (gpio, memory, bus) can be accessed through function pointers which are registered at time when calling the init function. The directory structure can be set up like #smbear suggested
I am writing a linux kernel driver and am running into a strange issue which perhaps stems from my lack of understanding. The program I am writing is a kernel module that is attempting to do some communication over a GPIO. The communication protocol is simple (toggles high or low depending on what I am passing).
SITUATION There is an existing driver that is using a GPIO that I am interested in. It also uses it for communications, but only reads and does not write. My driver only does writing. The communication protocol we both use is the same. My module calls GPIO_REQUEST after the existing driver has set itself up (I do not have access to the source of the other driver).
Any attempt to get the gpio via GPIO_REQUEST will result in the driver resetting itself. I have confirmed this behaviour on the osciliscope.
QUESTION How can two drivers share a GPIO? I am assuming that my GPIO_REQUEST call somehow takes away control of the GPIO from the other driver and that calling GPIO_FREE does not fix the situation (causing the reset).
I would ideally like to "borrow" the gpio, set the direction to output, write my data, and then return it back to the other driver.
Note: Willing to modify kernel source if need be.
My question is going to be rather vague but I will try to explain as detailed as I can what I am trying to resolve.
Trying to learn Linux kernel USB stack I have started to think of making a simple USB driver for my Atmel evaluation board based on ARM M0+ MCU to run away from Windows tools (Visual Studio plugin).
I have spent few days learning kernel's USB API and come to conclusion of how to make this. My driver aims to make my board connected to PC through USB cable act like a simple USB flash drive. Making that I then can easily program it with a new version of firmware written by me.
I have found that I need to find out specific interface (I am talking about interface in terms of USB specification, not interface we used to use as a code abstraction) that holds an endpoint (pipe) responsible for interaction with flash memory. And then I can map it to character device and interact with it using standard I/O operations that are described in struct file_operations structure.
Simply using cat on /proc/* file descriptor that was created by USB Core subsystem I have investigated that interface responsible for interaction with flash memory holds bulk endpoint (likewise, this terms come from USB specification, CMIIAW) that act as a "descriptor". Linux kernel USB Core subsystem gives neat interfaces to talk to different kind of endpoints whether it control, interrupt, bulk or asynchronous endpoint.
Now I have come closer to my very question.
Also the main transfer unit in communication between two USB devices is abstraction called urb - you allocate it, you fill it, you send it to USB Core subsystem, you read it if it was IN type of urb and, finally, you free it. What is confusing for me and tightly related to my question is the next API include/linux/usb.h:
static inline void usb_fill_bulk_urb(struct urb *urb,
struct usb_device *dev,
unsigned int pipe,
void *transfer_buffer,
int buffer_length,
usb_complete_t complete_fn,
void *context)
Assume I have obtained an information from board's datasheet about where to write a program code. Let's say, we have 0x00100 - 0x10000 memory region. I will compile my code, obtain a binary and then using standard Linux tools or writing a simple user-space wrapper application I will use lseek to set file's offset to 0x00100 and write system call provided with a buffer (binary compiled previously) and it's length.
In kernel space, I will have to allocate urb in write system call handler, fill it with a buffer sent from user space and submit this urb to USB Core.
BUT I can not find a way how to specify an OFFSET set earlier by lseek. Do I miss something? Maybe I missed some concepts or, perhaps, I am watching in a wrong way?
When your embedded Linux device acts as a USB mass storage device, the flash as a peripheral on Linux device is unmounted, and the gadget driver is loaded. Linux then loses control to the flash, and now the PC connected to your Linux device fully controls the flash. This is because a flash as a USB device can only has one USb host.
The gadget driver works purely in kernel space. It does not receive or transmit data from/to user space. It calls vfs_read() and vfs_write() to access the files on the flash, with an field offset. The offset is got from the USB commands sent from your host - Windows PC.
There is no way to specify offset using USB subsystem's API. I misunderstood whole conception of USB as communication protocol, unwise me. You must first learn underlying protocol your device uses to communicate with others.
If your device acts as a USB HID device then learning specification of how to exchange data with USB HID device is the way to go. If there is something proprietary then you can do nothing but reverse engineer it (listening USB packets with a sniffer on system where a driver for your device exists).
As for my board it has embedded debugger that serves as a communication module besides being debugger itself. Specifically, my device is equipped with EDBG and here is a link on description of protocol it uses for communication.