For some reason, I can only remotely control a server containing FPGA (Intel Arria 10 GX FPGA). But when I use the command in Intel OpenCL for FPGA to find the driver, I cannot find the FPGA device that can be used.
The command is as follows:
aocl diagnose
Output result:
enter image description here
Later, I used hardinfo to check whether FPGA is included, but unfortunately there is no useful information.
The only thing related to FPGA is that I found two files about fpga under my server (Ubuntu16.04). Since I am using FPGA for the first time, I don't know what this file represents.
enter image description here
In addition, due to network problems, I have not yet been able to install OPAE for testing. I would like to ask if there is an easy way to verify whether the FPGA is successfully inserted into the server.
You can check with lspci | grep "FPGA". The lspci command lists all devices connected to a PCIe slot, whether a driver is installed or not. If you find the FPGA in the list of devices, it is installed in the PCIe slot on the mainboard.
Related
In device driver programming we are using following items:
1. Device driver code
2. Device file
3. Actual physical Hardware (till now not used in my coding)
4. User space application code
What I understood is device file is a intermediate bridge between device driver code and user application code. And device file is a temporary (like bidirectional pipe) buffer.
Can anybody clarify me whatever I understood is correct? Also explain me how above four listed things are communicated internally in kernel. Even tried from LDD3 book, but still I am not getting correct picture.
I want to read the GPS data from my android phone inside the kernel space. I want to write a device driver for my GPS and request data through it. But unlike external devices I could not find the Vendor Id and device Id of the GPS hardware or the SOC on which it is installed. Can someone help me with how to collect the details required for writing the driver?
Thanks.
You already have found one of many problems with SOC and device drivers. Therefore another approach is used in the linux kernel: Platform driver and Platform devices. You wont need any Vendor IDs and such stuff.
I recommend you to read some tutorials and get started with it:
Readme: https://www.kernel.org/doc/Documentation/driver-model/platform.txt
Code example for CAN: https://github.com/torvalds/linux/tree/master/drivers/net/can/ifi_canfd
Disscussion about difference: What is the difference between a Linux platform driver and normal device driver?
Sadly I am not able to answer your questions on how to get those id's.
Is there any way in any Linux-based OS to access the instructions sent to have it transfer the instructions meant for the GPU to an external device connected via USB3.0 (and, obviously get the pixel output back)?
In Windows there is no native support for this kind of thing. Although many external graphics card exist which connect to a PCi slot, I didn't come across any USB ones.
Is there any way to accomplish this with native support of any of the Linux OSes?
EDIT: I was misunderstood, as far as I can see the comments. I want to program an external graphics card, I'm just looking for a way to get the GPU instructions to get to my device and get back the pixel array.
My goal is to create a virtual USB char device (not block device) for Linux 2.6.32 and above (I use debian squeeze) that would be recognize by the system.
I would like that this device be listed with lsusb as a normal USB device, and that every application could use libusb in order to open the device, and send control message, and make bulk write/read. But behind this virtual device, it's behavior would be set by my application. I want to set it's product ID, it's vendor ID, answer to USB status, and bulk read.
I've read some posts about how to use USB/IP in order to create a virtual USB device, and that's exactly what I want to do
Installation and emulation of virtual USB Device
http://breaking-the-system.blogspot.fr/2014/08/emulating-usb-devices-in-python-with-no.html
But unfortunately, when I tried with 2.6.32 kernel and above, I didn't succeed making it work. So I looked at how to create a kernel module that would create the virtual device :
http://pete.akeo.ie/2011/08/writing-linux-device-driver-for-kernels.html
This one looks great also, but the sample provided doest not indicate how to make it an USB device.
I've seen some post talking about it with windows but none that could help me with Linux.
I would like to avoid buying some USB programmable cards when it can be done with software.
Have anyone any leads on how to make the first methods works under newer kernel, or convert the sample code of the second method for making an USB device ?
I have fixed the code of http://breaking-the-system.blogspot.fr/2014/08/emulating-usb-devices-in-python-with-no.html (first method using USB/IP) to work with linux 4.3.
In the original code are missing USB requests like set configuration and get status. Without the implementation of all USB requests used for the OS driver the code will not work.
The fixed code can be downloaded in https://github.com/lcgamboa/USB-Emulation .
I guess raw-gadget kernel module is the thing that you want?
you can check the dummy_hcd and tests directory inside the repo, it will guide you how to create a virtual USB device
I want to scan the signal strength received from 3 AP.
I would be happy if that could happen every 300ms (max.500ms). I flashed OpenWRT on the routers.
I was seeking for a good tool to do that.
First I found iwconfig which worked, but only with networks that I was connected to. So I used iwlist (iw didn't work- maybe I need to update it?). Do you know how accurate is the output of it? Can I trust it?
After that, I came across the IOCTL. It looks really powerful* and professional. But is the output from getting the signal stregnth from a WIFI more reliable than the simple method like iwlist/iw?
*even too much powerful as I failed to compile any program I wrote using it
If you want to determine the signal strength of WLAN access points to which you are not connected, scanning is the right way.
The scanning is performed by the wireless network card with much or little "help" from the driver, depending on the design of the wireless card. There are cards (chipsets, to be more specific) that have their own processor and run their own firmware code independently from the host computer. On the other end, there are "stupid" cards where the driver on the host computer does most of the work.
Between the driver and the rest of the operating system, there is an interface (API) for sending commands to the driver and reading back information in a standardized way. With Linux, there are at least two different APIs. The older one is named Wireless Extensions, and the newer one is named cfg80211. Normally, a driver supports only one of the APIs. Most current drivers use cfg80211, but there may be older drivers that still use Wireless Extensions.
For each of the two APIs, there's a user-space tool (or family of tools) to use it. For Wireless Extensions, there is iwconfig (and iwlist, iwpriv etc.) For cfg80211, there is just iw.
So, the questions about the right tool depends on what API the wireless driver uses. To add confusion ;-), cfg80211 does some emulation which allows you to perform some Wireless Extension calls to drivers that use the newer cfg80211 API.
Regarding your questions about ioctl(): This is a generic method for communication between user-space and kernel-space in Unix operating systems. The old Wireless Extensions API uses ioctl(). The newer cfg80211 API does not use an ioctl()-based interface, but uses nl80211 instead.
To sum it up: whether to use iw/cfg80211/nl80211 or iwconfig/Wireless Extensions/ioctl depends on the driver or your wireless card.
Regarding your desired scanning interval, I would say that 300ms is rather short. This is because for a useful scan, the client needs to leave its current channel for a short time, switch to another channel and listen to signals from other access points on this channel. Since leaving its channel interrupts communication, these off-channel times are usually kept short and are carried out infrequently.
Calling iw <dev> scan or iwlist <dev> scan, respectively, will not necessarily cause a new scan, but may return an old (cached) list of access points. Depending on your wireless card/driver it may be (im)possible to enforce a new scan.