I have buy an usb video grabber on ebay but I haven't received an official device, it's a fake, and this one is the only one fake not supported by Linux. I would like to write the linux driver, but I have no knowledge on driver dev. Where can I find tutorial for driver dev learning on linux?
The device is an easycap dc60++, identified as fushicai usbtv007. More details here : http://linuxtv.org/wiki/index.php/Easycap#Known_Easycap_devices
It works on win7, so I can easily sniff usb protocol.
Thanks you in advance
IMHO, the best way to learn how to develop drivers for the kernel is to take an existing driver (best if it's from mainline) that is similar to what you want and look at how they're doing it. For function references, head to your favourite LXR site and search it up.
You could look up Linux driver development on Google and find some tutorials but I wouldn't recommend it for anything other than to get started since they're likely to be outdated or use deprecated kernel APIs.
Otherwise, there's always libusb if you don't want to get into the world of kernel driver development.
Good luck.
I made an experimental userspace driver for this device:
https://github.com/memeruiz/usbtv007
Hopefully somebody (or me) will take this and make a proper kernel driver for it.
I've made a driver for the device in question (https://lkml.org/lkml/2013/6/10/381). There's a big space for improvement and I'd be very glad if you could get involved.
The following documentation is helpful:
Linux Device Driver, third edition, book.
PDFs: http://lwn.net/Kernel/LDD3/
epub: http://v3.sk/~lkundrak/ldd3/
Video4Linux2 API: http://lwn.net/Articles/203924/
Videobuf2 API: http://lwn.net/Articles/447435/
When it comes to a good example, have a look at the drivers/media/usb tree, particularly the stk1160 driver.
I didn't yet have a look at Federico Ruiz's libusb driver for the device, but it seems he mostly figured out the same things as I did about the hardware. I suggest you take a look at it though, as I'll certainly do.
Also, linux-media list is probably a better place to ask questions like this. I've got here mostly by accident and there certainly are much more capable people on the list.
Have a great day!
Related
I have USB oscilloscope Velleman PCSU 1000 which is Windows-only, and I'm thinking of ways to make it work in Linux.
I've come across interesting publication on driver reverse-engineering, so, at least in theory, I can reverse-engineer the driver for the oscilloscope, and then write Linux driver for it. But I have no idea how to make their proprietary software work in Wine with my new driver? Is it possible?
If not, then it seems I have only one option: write not only the driver, but reimplement the software as well. This is awful amount of work, unfortunately.
And, as far as I know, there is no common device class for this kind of devices, so I can't write some generic driver to make any other similar software work with the oscilloscope. Right?
Anyway, any suggestions and ideas are highly appreciated.
Context
Debian 64 bit. kernel 3.18.x
Litterally struggling to understand how a network driver is initialized.
I mean how to choose which flag to set. I dig in the kernel for days now to train myself. The card setup is the only point I miss.
I take the intel 82574 as an example. I downloaded the card's datasheet, saw many information but not a clue on how to setup the hardware.
Question
Where to start to know what flags to set ? The datasheet didn't helped me (i am not very experienced but willing to learn).
Please give me a starting point, a tip or anything to help me understand what is going on in the already written open sourced driver.
How can a developer knows how to initialize his nic ? (yes reinventing the wheel the time to understand)
You'll need to read the source code of the kernel module that handles your specific NIC.
EDIT: Of course, to develop such a module, you'd usually just use a register map as specified in a data sheet or application node; often, manufacturers develop their linux drivers themselves, so the driver developers might even be the same people that developed the chipset (because it's really handy to have a platform to test against -- it's impossible to test hardware without having something like a driver, so you might as well write a proper driver).
Furthermore, devices often come with code examples -- no one is going to build a device based on an IC that he has not seen in action.
If you've got access to neither proper documentation nor source, you can only reverse engineer - and that's an incredibly large field.
Using your example with the Intel 82574 Network Adapter, Intel provides a zip file of the source code used to build the Linux driver. The driver is like all drivers in that it hooks into the OS API for Networking.
The Linux networking API is document on both the linux.org site and discussed on popular Linux sites like lwn.org. Below is the link to lwn's chapter on Network drivers using the networking API called NAPI.
https://static.lwn.net/images/pdf/LDD3/ch17.pdf
You'll notice in the Intel igb driver source code that the NAPI net_device data structure is one of the first things that is setup. It registers the driver with the OS. This way the OS knows which igb functions to call when loading/unloading the driver, or when needing to send/receive data.
The igb functions read/modify/write the necessary bits in the 82574's memory-mapped registers that control and monitor the device. The device registers are all documented in the 82574 datasheet available on Intel's site. And this is usually the case for almost any networking company like Broadcom/Chelsio/Mellanox/Marvell.
Hope that helps a little more.
I would like to learn how to write device drivers for IBM AIX OS.
I wanted to know is there any way to do this?
Can I download AIX? any books or docs available on the same?
If not, then if I learn how to write drivers on FreeBSD/Linux will that knowledge help?
Please suggest me..
Thanks a lot in advance.
Marc
Writing drivers for other platforms like BSD or Linux helps but it also hurts.
AIX has a preemptible, page-able kernel which makes it really weird to write for. A thread, in a system call, can get preempted. This is unusual for kernels. Data structures in the kernel can be paged out. This is also unusual. The locking mechanisms are unusual as well.
As you can tell, finding info about AIX is rather hard. The pubs actually does have most things documented but finding it is rather challenging because IBM and AIX tends to use their own terms.
There is a fairly good book that was published years ago. You might find it on ebay or something about writing device drivers for AIX.
There are also partner programs that IBM has, google "Partner World", that try to help.
The other thing you will find (especially with the partner programs) is AIX is like the red-headed step child of IBM. The folks at partner world want to talk about Tivoli, Lotus, DB2, Rational, etc. and few will know much / anything about AIX. But they do have access to equipment, etc.
Its going to be a tough road to climb. I keep wondering, why you have decided to do this. The market for AIX driver writers is nil.
Anonymous disinterested help (posted as a guest!)
Found this rather obsolete book on AIX 4.1,
http://bio.gsi.de/DOCS/AIX/SC23-2593-00.pdf
I haven't used Visual C++ before, however I'm starting a project that will require me to use it.
I want to get raw data from the USB. Almost every website tells me that I need to write a device driver for it first... Well I know that!
But I want to start simple - with my wireless mouse receiver, which obviously has a driver installed, which works. How can I access the contents which that receiver provides to the computer, using Visual C++?
This is a great project - a ton of fun too. Perhaps you can find some resources from this related post. I go into a lot more detail there. But I'll answer a little bit here too.
First off, you definitely don't want to write a driver. The time of writing drivers is mostly behind us. :) At least for what you are trying to do in particular. As I detail in the aforementioned post, we now mostly use HID descriptors to communicate with HID (usb) devices instead of writing drivers. This is awesome because it seriously simplifies the task.
I will highly recommend you or anyone in the same position use the libusbx library. It makes things very simple and straightforward in terms of communicating directly with HID devices. Again, see the post for a much more involved answer, but this should do it. Good luck!
I have a Linux network driver that was originally written for 2.4 kernel. It works perfect.
I want to port it to kernel 2.6.31 and then to ARM Linux with same kernel i.e. 2.6.31. I have actually done some minor changes to the driver so that it is able to compile under kernel 2.6.31 and it also loads and unloads without crashing. It also cross compiles for the ARM Linux. But I am unable to test it on ARM so far.
How do I check that the driver is fully compatible with the target kernel, and what considerations shall be made to make it compatible with ARM.
The driver is a virtual network device driver.
Thanks in advance.
Maybe you could use Qemu ( http://wiki.qemu.org/Main_Page) to emulate an ARM platform to be able to test your driver.
You cannot check the driver like that - you have to consider the API changes within 2.6.x series kernel. The changes are quite significant and the overall of the API's from the 2.4 series which is not currently in use.
I would suggest you to go here to the Amazon book store for this book in particular. The book is called 'Essential Linux Device Drivers', by Sreekrishnan Venkateswaran. A very well detailed explanation that will be your guidance in ensuring it works properly.
Since you mentioned the device driver is a network, presumably char device (You're not accessing it in blocks), well, the good news is that the 2.6.x series kernel APIs for the character devices are significantly easier and more centralized to focus on - in fact a lot of the framework is already in place in which the author of said book explains very clearly.
By the way, the book focusses on the latter 2.6.x series after 2.6.19, so this will help you clue in on what needs to be done to ensure your driver works.
You did not specify the ARM chipset you're targetting?
As for testing... well.. perhaps the best way to do this, this is dependant on how you answer the above question to you regarding ARM chipset - if its ARMv6, then perhaps, a cheap android handset that you can easily unlock and root, and pop the kernel in there and see what happens - sorry for sounding contrived but that's the best thing I can think of and that's what pops into my head, to enable you to test it out for ease of testing :)
PS: A lot of cheap ARMv6 handsets would have kernel 2.6.32 running Froyo if that's of any help!