I'm trying to write a linux driver to a device that i have the windows driver of (Similar to the case described Here, but a different device)
I'm using Libusb for the communication on the linux side, and SourceUSB as my USB sniffer (on the windows machine). Now I think I've replicated the controls and bulks properly, but I can't really test the linux log against the windows one. I'm running Ubuntu 12.04 on a VM.
So my questions are:
Is there a multiplatform logger? That could really simplify the log compare process.
When I attach the USB device to the VM - I get the VM driver in Windows. Sniffing this device gives me exactly what the device sees, right? I mean - Is this where I want to sniff?
EDIT:
I've compiled my application on windows (libusb is cross platform - A big thanks to libusb developers who did such a good job) and my application worked properly.
When sniffing the VM driver while running my application on linux, I see the requests to the USB as VENDOR_DEVICE instead of CONTROL_TRANSFER and BULK_OR_INTERRUPT. This seems to be the problem if I understand correctly, since this is what the device "sees".
So I guess my problem now is why does Linux sends my requests as vendor.
ANOTHER EDIT: Problem solved:
Listening to the VM driver gave me the wrong requests (I was listening to the VM driver traffic, not, as i wanted, the traffic of the my USB linux driver
Libusb is perfectly multiplatform. It took me a few minutes to get my code to compile under windows, and from there it was pretty easy to debug and compare logs
You can use Wireshark to capture USB traffic. This page explain how to do it for Linux and Windows : CaptureSetup/USB
Related
On Windows (either native or running on a virtual machine from a Linux host), I can open a serial port in 8N1 mode and my desired speed of 921600 bps, and an incoming test string arrives fine from an external hardware device: HELLO WORLD.
On Linux, however, with same serial configuration I can only get slightly garbled text: H�LLO �OR�D.
However, lower baudrates (such as 460800 bps) work fine in both Windows and Linux. So by using 921600 bps I'm clearly hitting a speed maximum, imposed by some component of Linux.
Why does this happen? Does Linux have a default limit on serial baudrate? Is there anything I should configure to enable baudrates higher than 460800 bps?
Some more details:
The external device's serial output is connected to the computer via a CH340G-type serial-to-USB converter.
Tested software is TeraTerm and PuTTY on Windows, picocom, minicom, and screen on Linux.
Tested O.S. versions are Windows 7, Ubuntu Linux 16.04, and Ubuntu 20.04.
As mentioned (but it's worth repeating it), the text can be read fine if opening the serial port on Windows running from a VirtualBox virtual machine, from the same Linux host that is not able to cope itself with the mentioned baudrate! I guess this works because VirtualBox simply does a USB device passthrough, so whatever limits Linux has, they don't apply to the virtualized Windows.
In theory, my Linux seems to support the requested speed: the file /usr/include/asm-generic/termbits.h contains the definition for B921600 (together with lower ones such as B460800, and lots of other higher ones that go up to B4000000).
There is/was a bug on the CH340 driver.
Apparently, the baud rate error for 921600 bps was more than 7%. I guess that's what you might be experiencing.
I don't have any such devices so I did not research this further and I'm not sure if the patch or patches written to fix this issue ended up on the mainline kernel.
You will have to go here and find out yourself.
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.
Received my Jetson TK1 yesterday. After unboxing it and configuring the Linux GUI, rebooting the device with a mouse (cordless) attached to its USB 3.0 port takes it to some sort of Command line page where it probably loads some files and then the screen starts printing " [ . ] ". Nothing happens beyond that until I restart the board without any USB peripheral and then the device boots into the normal Linux GUI. Unable to figure out what's wrong with my board and why is it not working properly.(I am a newbie to LINUX)
P.S.: Connecting the monitor via HDMI after switching on the device gives no visual output, just a blank screen. Is it possible to connect the device via network adapter for remote access even it the screen is running blank?
The question is quite old, but as some people might get frustrated with it, I'll provide the answer for most probable cause.
Upgrading the board running 19.X release causes libglx.so to be corrupted. The issue have been actively discussed on NVIDIA forums and the best way to solve it is to upgrade to 21.X.
Otherwise, you can try recovering the libglx.so in the usr/lib/xorg/modules/extensions/ from Tegra124_Linux_R19.3.0_armhf.tbz2.
Could you possibly provide a bit more information about your situation.
Are you able to go to command mode by pressing 'CTRL+F1' or 'CTRL+ALT+F1'?
If that works, it means your Jetson operating system is working but only the GUI is not working properly.
Yes, You can use ssh to your Jetson (what I do) if only the GUI of Jetson is broken and your OS is working properly. Note that in order to do so you need to know ip address of your Jetson and perform some possible router configuration.
Note: Sometimes if you have a USB device connected to your system (jetson), the jetson might mistakenly assume the USB is storage type and therefore tries to boot up from the USB. This leads to failure since it can not load any OS of the USB. (I'm not sure if this is the case for you)
I am working with a SOM mounted on a carrier board running Ubuntu 14.04 with the generic 3.13 kernel.
While testing out the peripherals, I hit a problem with serial communication.
Basically, I can transmit data from the custom platform to an external Linux machine, but I can not properly receive data from the external Linux machine to the custom platform.
Through my research I have messed with all sorts of BIOS settings, baud rates, hardware flow control, parity, etc. Nothing has worked. Most info I have found online just says "Make sure your baud rates and other settings match", and they do. It is not my first time working with Linux serial ports. But it is my first time encountering a problem like this.
Does anyone have any suggestions, recommendations, or has anyone ever seen an issue like this before?
More info: We are running a quad-core Intel Atom micro with a custom serial breakout interface. The serial port is at /dev/ttyS0.
EDIT (clarification):
If I set up a session in Picocom or Minicom, I can send characters from our custom platform (running Ubuntu 14.04) to another Linux PC (also running Ubuntu 14.04). However, if I try to send characters from the Linux PC to our custom board, I sometimes get nothing, and other times get unrecognized characters (they show up as bubbles with question marks in them).
I can also simply echo a string to /dev/ttyS0 on the custom platform and receive it on the Linux PC. I just can't get it to work the other way around.
and I want to know if my chipset is capable off doing those things
My chipset is a intel centrino advanced 6200-n on a sony vayo laptop running on windows 7.
Now, I know that windows is only capable off listening, so I boot backtrack 4
from a usb stick.
I also want to know if a live distribution can work flawlessly with the wificard even if it does not support formentioned things, because I try'd to use wget to download something
and it says it ca not resolve the address?
thanks, Richard
Intel centrino advanced 6200-n does support both monitor mode and frame injection with iwlwifi driver. There are some intricacies involved on driver side though so it is best to use very recent kernel to make it work reliably. The patches which make this work well are expected to be part of Linux kernel version 3.5, until it's released you can build kernel yourself from iwlwifi.git tree:
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi.git
Instructions on building kernel from a git tree:
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
It should also work with older kernels.
As for the fact that you couldn't wget something - have you connected to wireless network at all? Standard client mode in iwlwifi works very well even with old kernels.