I'm trying to certify USB on our device that is running Linux 4.14. For windows systems we were using https://www.usb.org/usb2tools. For linux the only option I have found is a kernel module called EHSET. Unfortunately I can't manage to get it working, can You please help?
I have added the following configuration:
CONFIG_USB_HCD_TEST_MODE=y
USB_EHSET_TEST_FIXTURE=m
Then on the system I type in modprobe ehset. After this looking at the source code of ehset.c I assumed that inserting USB stick with VendorID:
0x1a0a and ProductID: 0x0108 would start the single step procedure, but it doesn't do anything. The device is loaded as a regular USB stick.
I have not seen any documentation on this topic. Is the kernel driver the only way of testing it in linux and if nothing ready is available do You know what is the procedure of using it?
Thanks in advance!
Related
I'm new to device drivers in Linux. And my first day task is to debug driver using GDB in Linux.
I need to debug some XYZ (PCIe device driver supports ethernet) device driver to know about the flow and what is going on device's registers and all.
I have installed the driver with patch file and insmod command.
The device is working properly. But am not getting any solution to debug the device driver.
All I know is that how to debug C program using GDB in Linux(fedora20). I got one link similar to my Problem but from that also I have not got any knowledge.
Can anybody please share your thoughts that how can I start from scratch.
I am very specific to learn about Debugging device drivers in Linux. Especially that init or probe function inside my driver I need to know the flow.
The gdb debugger is useful to debug user-space application level programs (since it uses ptrace(2)).
For kernel code, things are different. Consider using kgdb (I don't know the details). You might also add debug prints ....
I recommend at least reading more about operating systems, e.g. Operating Systems: Three Easy Pieces (freely downloadable), and reading something about Linux programming (perhaps the old ALP, and also intro(2), syscalls(2) and related stuff). Don't dare coding Linux loadable kernel modules without good familiarity with Linux programming (in user-land). See also kernelnewbies.
BTW, you should prefer writing user-land code than kernel modules. A very simple rule of thumb is to avoid writing kernel code when possible.
To begin with, you may need to understand basics of device driver and kernel in linux. Subsequently focus as per the type of driver in-hand. You also need to understand the functionality (specification / manual / datasheet) of the device you are working on.
The very basic approach for debugging can be using printk. Normally there will be debug logs that can be enabled through compilation flags. If it is present, enable it so that it can give important pointers else you might need to add it on your own.
Start with verification of driver registration and verification of loading of your driver (static or loadable module as per your requirement). Check whether it is getting listed as part of sysfs or proc as applicable. Check whether probe is successful and subsequently the appropriate read/write/open/close/other calls as per your driver / device functionality.
The dmesg shall be very helpfull for viewing the kernel messages. There are also tools like kdb, LTT, strace that can be useful as per the scenario.
I want to write a driver for sensor which can tell me if my yoga 2 pro is in tablet mode or not.
I read some about writting modules but as far as I know, I need to know address in memory which belongs to this device (hope it's correct), and here is my question.
How can I find information about this address?
Or what should I do to find this address?
Both in Windows and in Android you absolutely don't need to write a driver for this purpose. To identify Tablet/Laptop mode, you need just one sensor - accelerometer. In Windows 8.1 + this functionality is built-in, but in case you wish to build your own application you can use an example from here: https://code.msdn.microsoft.com/windowsapps/Accelerometer-Sensor-Sample-22982671
In Android, you have a Java API to all sensors:
https://developer.android.com/guide/topics/sensors/sensors_overview.html
However if you have a custom Linux installed on your Yoga, there indeed may arise a need to add a driver. As of now, the most useful solution are IIO drivers that are part of Kernel:
http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf
If there aren't already there, you'll have to rebuild a Kernel and include those drivers. If you don't know how to find a device address, you have to learn for a while about Linux Kernel in general. Anyway, some tips:
Sensors are normally defined via USB/HID interface
If you still have your Windows along with Linux, you may go to
Devices Manager and there you can easily reach Sensors and see what
address is used by a driver.
I am using the LPC1788 evb cortex board manufactured by emcraft.
In that the linux source which is provided along with the board is not configured for IRQ.
this I came to know by seeing the /mach-board/mach/gpio.h file. but in my project I need to control the device using interrupts.
I am creating my custom device driver and the driver is unable to get IRQ number, as according to me this is due to gpio.h file I feel.Please guide me to over come this issue.
thanks
any suggestion and links for reference are much needful to me.
I want to install the drivers of the video camera on my linux computer.
I write the command:
modprobe usbserial vendor=... product=...
what I expected to get was ttyUSB0 (or sth simmilar) in the /dev directory.
Instead what is getting installed is sg3 (whatever that is) and when I run a program that is supposed to send a command to start recording I get no results (but no errors either).
(I changed what I had previously: fd = open(/dev/ttyUSB0,...) to /dev/sg3 but I guess this is not a configuration that enables sending this kind of data.
What might be the problem? (Sorry if it's a basic question)
cameras and linux can be tricky.
Start by plugging in the camera and running
lsusb
google for the id to see if anyone has a step by step tutorial or at very least can tell you which modules are needed.
Most common drivers seem to have been migrated to the kernel, so rebulid your kernel make sure the modules are built.
Some more obscure usb modules have to be built by hand.
I'm looking for either a kernel mode call that I can make from a driver, a userland utility, or a system call that will ask the Kernel to look at the PCI bus and either completely re-run its initialization, or initialize a specific device. Specifically, I need the Kernel to recognize a device that was added to the bus after boot and then configure its address space, interrupt, and other configuration parameters, and finally enable the device so that I can load the driver for it (unless this all happens as part of the driver load).
I'm stuck on the 2.4.x series Kernel for this, and am currently working with 2.4.20, but will be moving to 2.4.37 if it matters. The distro is a stripped down Red Hat 7.3 running in a ram disk, but I can add in whatever tools are needed to get this working (as long as they play nice with 2.4 series).
If some background would help clarify what I'm trying to do: From a cold boot, once in Linux I use GPIO to program an FPGA. Part of the FPGA, once programmed, implements a simple PCI device. Currently, after programming the FPGA, I reboot the system and Linux recognizes the device after coming up and loads the driver for it.
Instead of needing that reboot, I'd like to simply ask the Kernel to do whatever it does during boot up to find PCI devices (I have the Kernel configured to find PCI devices on its own, instead of asking the BIOS for that information, so the BIOS won't need to know about this device (I hope)).
I believe that Linux is capable of seeing the device after it is programmed but before a reboot, because scanpci will show the device after I program it, as will lspci -H 1. I just need a way to get it into /proc/pci, configured and enabled.
This below command will help the user to rescan it complete root hub.
echo "1" > /sys/class/pci_bus/0000\:00/rescan
You could speed up the reboot with kexec, if you don't figure out how to get the PCI scan redone. You could ask this on the LKML, if you haven't already.
unloading/reloading the module doesn't help, does it?
http://www.linuxjournal.com/article/5633 suggests you should be able to do it with 2.4 kernels using pcihpfs.
If that isn't working, maybe the driver doesn't support hotplug?
It would probably crash the system if you reconfigured the addresses of other PCI devices while they are in use.
A better way would be to just configure the new card. If your kernel has support for Cardus devices, it already knows how to configure a newly-inserted PCI device (which is what Cardbus is). You just need to figure out how to get the kernel to do it...
It should be possible for a kernel module to do this. Even if you can't get built-in hotplug code, you should be able to set the pci resources using calls to pci_bus_write_config_dword() and friends. There is probably some IRQ routing setup to do as well.