I started lately reading some articles about the kernel space and especially about device drivers. So I was wondering are there some minimal requirements for a device in order to make it easy to write a device driver for it?
A possibility to communicate with it from the kernel (PCI, USB, etc...) and documentation. Obviously a kind of hardware debugging process can improve things.
(This doesn't count as "minimal", but it does meet your desire to "make it easy".)
Some sort of testing mode, or device simulator, which allows you to
(a) see the messages that are being sent to it, so you can see when there is a bug in your code.
(b) stimulate events that cause communications to occur.
For example, if you are writing a driver for a burglar alarm, a way of triggering the device to send an alert from a window sensor, without having to actually throw a brick through a window.
Related
I am designing a USB keyboard with special capabilities. What information can such a HID device receive from the host?
Can I via USB:
Read data from a form on the screen?
Find out what OS the user is on?
Find out if there's been an error message?
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen?
Thank you!
The device can't get any of this information from a standard driver that the operating system supplies because that would be a security issue. It can receive any information that your own driver or application sends it. There are many ways to communicate with it - your device could present multiple interfaces (which will appear as separate devices), multiple endpoints, or use the control channel. You will definitely need to study the spec, and I also found this tutorial helpful.
I have done something similar and used the control channel to exchange feature data with a Windows application (over the standard Windows driver). On Windows, the API calls are HidD_SetFeature() and HidD_GetFeature().
On the device side, my hardware ran embedded Linux and I used the GadgetFS library to create a user-mode driver - much easier to debug than a kernel driver.
As others have said, you'll run into issues if you try this with a normal HID. However, there is a project called the USB Rubber Ducky. From their description:
The USB Rubber Ducky isn't your ordinary HID (Human Interface Device).
Coupled with a powerful 60 MHz 32-bit processor and a simple scripting language
The USB Rubber Ducky looks like a usb-device and is recognized as a HID, but is programmable. You can make a small script that will be typed onto the screen which will allow you to performs the queries you seek.
With the USB Rubber Ducky you can:
Read data from a form on the screen? Yes
Find out what OS the user is on? Yes
Find out if there's been an error message? Yes
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen? Yes
If you aren't hoping to buy this device, at least their firmware is on github so it can provide you a starting point
Im working on an fpga controller connected through pcie.
The only way i can debug the hardware is using chipscope. So i execute commands through my driver and check out the signals from the fpga.
The problem is that it takes a lot of time to build the project and load it to the fpga every time i want to check a signal to debug the project.
Is there an easier way to debug an fpga connected to pcie?
Is there a way i can simulate all the pcie signals and not have to run the fpga at all?
One thing you can do is to capture a trace of the PCIe transactions into a buffer, then read that out and replay it as the stimulus in a testbench during simulation.
You can use a BRAM or possibly FPGA-attached DRAM for the buffer.
You will probably need an alternate path for reading out the buffer. Xilinx has a JTAG to AXI master that you could use to read out the buffer. Or if your PCIe is stable you can read it out that way.
As mentioned in several comments, you want to do detailed debugging in simulation rather than in hardware. The loop time to debug via chipscope, determine the problem, come up with a new set of signals to probe, recompile, and push new code into the FPGA. This is a very painful process compared to debug in simulation.
If you are trying to debug PCIe, you can either get a PCIe BFM from a commercial vendor or possibly off of OpenCores, or you can use the capture buffer described.
If you are trying to debug your own logic and PCIe only comes in because that is the interface to the device, you are best off writing your own BFM that drives transactions to your internal logic as if it were the PCIe core. Reproduce the problem in sim, debug there, then go back to the FPGA once you have good code coverage and a decent suite of passing tests.
For a mouse, if I issue the command cat /dev/input/mouse1 and then move the mouse, there will be outputs in the console. From this I know that the mouse works.
But for the touchpad of my laptop, which is mouse0, I see no output when I issue /dev/input/mouse0 and touch the pad.
Then how do I know whether drivers of devices like my touchpad are really working? Whether they can really communicate with the operating system?
this depends upon how your driver wishes to communicate with the device and provide a response to you.
your driver needs to create a procfs or a sysfs interface like your mouse did.
so if your driver creates such an interface you can surely see but you have to look for them, sometimes they are not easy to find with their terminologies.
needless to say, they exist and they are communicating with your OS if they are working, but have they provided a procfs or sysfs interface, that is driver specific and could not be said just right away, some documentation or code would be required.
I am very interested in device driver programming .I have started reading the LDD3 ,there author said
"to become a device driver programmer you have to understand your specific device well"
can any one tell me what is the meaning of the "understand your specific device" .what are the thing I should know before writing a device driver.
Thanks
That's a basic list with software and hardware combined.
The Operating System driver API
The processor architecture as it relates to hardware interfacing
The 'bus' structure that interfaces the device hardware to the processor
Interrupt Handling
Dma Control
Processor Caching
Processor MMU control
OS Semaphores and scheduling
Data/Byte Alignment
Assembly language when needed
Control of Instruction Execution Order and Optimization
Consideration of performance issues
What's IO and memory mapped hardware ?
http://www.cs.nmsu.edu/~pfeiffer/classes/473/notes/io.html
This link talks about generic hardware access in Linux device drivers.
http://www.linuxforu.com/2011/06/generic-hardware-access-in-linux/
This is specifically about USB hardware
http://www.beyondlogic.org/usbnutshell/usb2.shtml
Check lwn.net it never disappoints a device driver developer.
https://lwn.net/Archives/
Last, but not least, They have everythig, CPU, Memory, Camera, PCI..
http://www.hardwaresecrets.com/page/memory
-
Hi, I'm very pleased to share what I have learnt with you guys.
Yes, it is the basic need to know your device if you wanna be a device driver programmer. I also want to be a linux device driver programmer, or even more, though I have some device driver experience under other software platforms.
The reason why you wanna contact with it is that you wanna make it do something for you.
Normally, what it can do is the first thing you must know. It's very obvious that you will never send Ethernet frames through UART or SPI, right?
There exist various kinds of devices in the world, such as, storage device, FLASH, SD card, harddisk; communicating devices, network card, wifi; interconnected bus, PCI-express; how many there are.
After that, the next thing you will concern is how you can do to reach your goal.
To access the device, reading, or writing, there is usually a controller embedded in the processor. Here, when I say "processor", it means it is a core integrated with various kinds of controllers, no matter pc desktop or embeded system areas.
The Controller is the interface you will face, to work on the device behind the controller.
Through the controller, you can ask the device to do what you want. In the controller, there are registers, which are the deepest points the software can touch. Beyond that lies the hardware, as you are a device driver programmer, it is very common for you to communicate with hardware engineers to make things done.
If going into details about the register, there are control registers used to tell device what you want it to do, status registers, used to reflect the status of operations underway in devices, if interrupt is supported by that device, there are also some registers for you to deal with interrupts.
Well, I almost forget there are also data registers, whicha are used to store the data to be sent or written, or to be read by user. According to the specific implementation, registers used to store data from upper users to be sent or written and registes used to hold data from outside that will be read by users may be the same, or may be not.
In a normal way, if you wanna let someone do something for you, you should provide something to him first. Whoever wants to do anything, there must be some inputs to him, right?
in a summary,
action(read,write,or others) + data(you give, or you ask for) + status(what progress it is)
what it can do
how it does that, how to assemble the command cell, time sequence?
what you must provide it to reach your goal
genarally, two kinds of things you should provide:
if you ask for, where to store what you ask for;
if you give, where are what you give
how it reflects the progress of operations， polling or interrupts
Well, that is all I want to share with you.
Thanks.
I'm trying to develop a "virtual" video driver based on ViVi project example. It's virtual since it doesn't interact with any camera. It gets a video stream from a user program (C++) and also it acts as video driver for another user program (Flash) which displays the video stream.
So, if I have a /dev/video0. One program needs write frame to it and another reads one from. Is that possible?
I need this because Flash doesn't recognize this camera, so I use a virtual driver as a bridge from my grabber (which uses the real driver) and Flash.
Yes.
More generally, a device driver can allow as many simultaneous opens as it wants. Take a look at Linux Device Drivers for more info. You can use filp->private_data to store data relevant to the specific open instance.
For even more flexibility, a device driver isn't even limited to having a single device node in /dev.
There used the vloopback driver, which did exactly what you want to do. However, it wasn't part of the standard kernel. Some time ago, I wrote a library (dv4linux that intercepted libc read/writes to /dev/video to achieve something similar. The current version has serious issues with newer firefox's malloc handling, though. berlios.de may fo out of service soon.
Can a driver be used by two program :
It usually can, but it is driver dependant. When it comes to data capture, you often have one process which gets all the data, and other processes have only limited access to the driver functionnality. So in the end, the API is ok with multiple process opening a driver, but in the end it all depends on the driver.
Can the VIVI driver be used as a bridge driver :
No. It is a video capture emulation driver, but there is no "video output" or "video sink" capability in this driver. You will have to understant why flash doesn't work with your real driver, but does work with a virtual driver. strace is your friend.