I need your advice.
I want to achieve transactions between my pc and fpga by pcie slot.
I try to install a driver to do that but the driver don't see the fpga.
I run on terminal $ lspci and I take this picture:
enter image description here
Is there any way to connect xdma module with my fpga manually...??
What you see in the "Used By" column of lsmod does not mean whether some user-space program is using the module, but only if it is being used by other kernel modules. For example if you check the usb_core line from the lsmod output, you will see that it is being used by a bunch of USB/HID related modules.
The kernel module (or device deriver) is only a way to enable your system to comunicate with the particular piece of hardware. It only exposes its interface so the rest of the kernel (or userspace programs) can interact with it.
You will need for sure some user level software or application that makes use of the interface exposed by the kernel module.
I don't know for your particular case, but the interface that the driver exposes depends on the type of the hardware and the module implementation itself. It may expose some files to /sysfs, or add a new syscall (this is very unlikely, but it's a possibility), or make special usage of ioctl.
So, you should check for the module documentation, or look for some user-space program that knows how to interface with the driver.
Related
Questions
What is the purpose and use-case of the gpio-hog declaration?
Can a 'hogged' gpio pin be interfaced with from Userspace?
If a 'hogged' gpio pin cannot be interfaced with from Userspace, then is there any mechanism to configure GPIO pins in the dts file for Userspace interaction?
Background
I am trying to configure many (10+) GPIOs to speak with a low level chip from Userspace. I have spoken to the chip easily using sysfs exports, but both the documentation in the kernel and programming forums have me concerned about using this mechanisms in our production system.
Reading more kernel documentation I read about gpio-hog declarations and it seemed like the ideal mechanism to at least initially configure the GPIOs. From the documentation:
GPIO hogging is a mechanism providing automatic GPIO request and
configuration as part of the gpio-controller's driver probe function.
As well as setting the correct low level, vendor settings, I enabled hogging on the desired gpio pins and they came up reporting the correct settings. The problem is that the gpio's are seemingly owned by the kernel and cannot be interfaced with by any Userspace tools such as sysfs or libgpiod. This makes hogging essentially useless to me and also makes me wonder what it's real purpose is. I am exploring libgpiod as a last resort, but the documentation makes it seem that hogging should be the mechanism I use.
hog meaning - to take or use a lot of something in a way that prevents other
people from having it
so basically gpio-hog property tells the controller to set the pin high/low during bootup, and no other driver/user space would request it.
If you intend to use the gpio in user space you shouldnt be using gpio-hog
I am trying to write a network device driver for Linux. The device that I have has an API available that allows me to access all of the features I need through a shared object that exists in userspace.
I want to write a network driver such that I can make the device show up as a CAN interface. However, in order to interact with the device I need to use a specific shared object that exists in userspace.
The reason that I need a network device driver is to expose a CAN Interface that can be interacted with via the SocketCAN utilities.
Is there a way that I can write a network device driver in userspace? Or what would the best way for me to architect a solution?
Tl;Dr
Need to write a device driver for a device which can only be interacted with from userspace via a supplied shared object which exposes the API. I need the device to show up as a network interface in order to utilize the SocketCAN utilities and other applications that communicate with CAN interfaces in Linux.
What are my options here? What can I do?
Thanks!
So you are saying that there is no driver for your network device in kernel at all, and it can be only accessed via some user-space library? In that case shared library you mentioned should be communicating with your network device by memory mapping your /dev/mem file, in order to be able to read/write to hardware registers. Or perhaps by using some UIO.
So your driver should be also developed in user-space then... Then the actual question you should ask is how to use kernel CAN API from user-space? And is it possible at all in the first place? For answers I guess you should look at Documentation/networking/can.txt. And if the answer is "no" (means you can't expose CAN interface from user-space), then you should develop also some kernel driver which would interact with your user-space part, exposing CAN interface.
In ideal world the whole driver architecture would look like this:
But you need to use some (proprietary, if I understand correctly) shared library API to interact with your device. So I propose you to use next driver architecture, which depicted on the image below:
blue color stands for parts that need to be developed
magenta is for already existing code
In a nutshell, your app and driver both make a shim between SocketCAN API and shared library API.
So you need to develop 2 components:
Driver (on kernel side). It's in charge of:
talking to SocketCAN utilities
talking to your user-space application
Application (in user-space); it's probably should be a daemon, as it's gonna be running constantly. It's in charge of:
talking to shared library
talking to your driver
The last question remains is which kernel API to use to interact between your kernel space driver and user-space application (marked as IPC on picture). It strictly depends on which kind of data you are going to send between two, and how much of data you will want to send, and which way of sending is most appropriate for your task. It may also depend on your shared library API: you probably don't want to spend much of CPU time to convert messages format (as you already have triple context switching with this driver architecture, which is not really nice for performance). So it's probably should be something packet-oriented, like Netlink.
Next reading can be useful to figure out which IPC to use:
Kernel Space - User Space Interfaces
Linux kernel interfaces
At present, I have a Linux 2.6 kernel module which accesses a certain device via pci_get_device() and pci_read_config_dword(). In future, the module shall be modified to also work a different machine which seems to have no PCI bus (/sys/bus/pci doesn't exist), but has the certain device at a fixed, known address. Now, I would like to have one module binary without parameters which works on both machines. To be able to load the module on the non-PCI machine, I think I must refrain from using pci_get_device() etc.; thus I have to get the needed config space info on the PCI machine in some other way. I could read it from /sys/bus/pci/devices/.../resource in my init_module(), but I gather it is considered bad practice to make kernel modules read files. Are there better ways to achieve my goal?
When functions like pci_get_device() cannot be used (because the module must work also with kernels that don't provide such functions), apparently there is no better way to get the PCI address info than reading /sys/bus/pci/devices/.../resource.
I resorted to doing so, using filp_open(), vfs_read() and filp_close() on the basis of How to read/write files within a Linux kernel module?.
I am new to kernel programming and I have dev_t value of a USB device.
I want to get the details of the device like vendor ID, product ID, or some other attribute which will vary from device to device. I want to do this in kernel space, and without loading my program as an external module.
I have came across a libusb library, however, as far as I know, it is used in user space. Is it possible to use libusb in kernel space also, like my requirement? If possible, how to import and set-up libusb so that I can compile kernel?
It is better to write a loadable kernel module for this task. Every time you find a bug you just have to compile your module against your kernel and load it. There is a defined framework in kernel for USB, use APIs that are provided by kernel to do things you are looking for.
Except That libusb is a user space library and there is no point of using it inside kernel.
In user space you can access USB related information using procfs/sysfs also.
I have been studying linux driver recently,
as those articles I read said, the device driver modules are likely to be automatically loaded on demand by kernel, I am therefore wondering about the recipe how kernel figures out which module to load for a specific device(sound card, I2C/spi device, etc), I also cannot thoroughly imagine how the kernel detects each hardware device while boot-time .
answers relevant to embedded linux are prefered , PC linux are also welcome !
3Q
I think you are mixing two different things, which is hardware detection, and on demand module loading.
In some cases, the kernel is explicitely doing a module request. However, in most cases, the kernel itself does not do any "on demand loading".
But wait, you must be mistaken, if I plug my shiny new webcam, isn't
the module automagically loaded ?
Yes it is, but not by the kernel. All the kernel does is calling a userspace program with so called "hotplug event" or "uevent" as arguments. On Linux PC, this userspace program is usually udev, but on embedded system, you can use for example mdev. You can find a more detailed explanation here and here
Regarding the second part of your question, the kernel is doing hardware discovery only if the hardware is discoverable. Example of discoverable hardware is USB and PCI. Example of non discoverable harwdare busses is SPI or I2C.
In the latter cases, the presence of a particular device on a given bus is either encoded directly in the kernel, or given to him by the booloader. Google for "device tree" for an example of the latter.
To sum things up : Hardware detection is done by the kernel, and module loading is done by userspace, with information provided by the kernel.