I recently downloaded new linux kernel source code and compiled on ubuntu. After my system is not recognizing any usb devices. Is there any changes required to compiling procedure or make files in order to enable USB host?
Please help me to get out of this problem. Thanks.
It is possible for the USB support to be disabled though incorrect or incomplete configuration.
You didn't mention how you configured the kernel though.
A good point to start is the existing configuration for the default Ubuntu kernel. There should be a config file in boot, like /boot/config-3.1.0-1-amd64.
Copy that file to your kernel directory as .config, then use make oldconfig to update the configuration.
When installing the kernel take care to create the corresponding initrd as well.
Related
Has anyone managed to connect a MicroBlaze instantiated in a Xilinx FPGA to anything other than the Xilinx tools (SDK or Vitis) for download and debugging?
I'm targeting a VCU29 and have licenses from Xilinx for Vivado etc; I have already extracted the libraries, source and GCC tools and constructed a makefile that will build my applications.
I'm resigned to using Vitis to load the initial bitfile but would really like to download the code and operate the JTAG from a tool that better matches SW development flow - Eclipse with OpenOCD? Perhaps over the built-in USB->Serial->JTAG interface? I believe I'd be content with just the interface offered through GDB.
I'd really like to know if anyone has tried this with either success or failure or maybe has one of those "Why don't you just..." lateral thinking ways of solving the problem.
Yes, my team does not use Vitis or SDK to build, deploy, or connect to MicroBlazes.
If you generate your BSP and a linker script with Vitis, you can then build using mb-gcc and link with mb-ld directly. To get these into your PATH, just source the settings script that Xilinx provides with their tools in <Vitis_root>/settings64.sh.
As for loading and debugging - if you source the same script, then you will have access to xsdb. Once you have XVC running (i.e. connecting to your board with Vivado HW manager), then you can launch xsdb and inside run connect or connect -xvc-url <host>::<port> if you are running on a different host. While connected, you can run targets to identify your MicroBlaze, and then select the MicroBlaze with target 5.
While you have the MicroBlaze selected, you can load <path to elf> and run a number of debugging commands. Just run help while connected to see your options.
I bought a Variense VMU931 inertial measurement unit (IMU) for a robotics project at school, and I am struggling to get it to reliably communicate with my laptop in Ubuntu. I am using C++ with termios to connect to it using 8n1 no parity blah blah blah. I've tried EVERY permutation of settings I can think of, and I still cannot reliably send commands to the IMU.
I called Variense support and spoke to the engineer that wrote their software, and he said it is a known issue. Evidently it works perfectly in Windows (and the Windows demo software worked fine with my device), but neither of us is aware of a significant difference between the USB Serial emulation in Windows and in Linux.
The constructor at the top of this file shows how I am opening and configuring the port:
https://github.com/jsford/FFAST/blob/master/VMU931/src/vmu.cpp
Any help would be great. I've been tearing my hair out over this!
Thanks!
Use the cu utility for running tests with different parameters.
To debug the issue: run the USB packet capture with Wireshark on Linux directly and also on a Windows VM running in VirtualBox/VmWare. Compare the traffic.
Check which kernel module is chosen and loaded for that USB device. Use /sys/ filesystem for that: this virtual fs has information from kernel about what's used. Also, the lsmod-kind of commands show the kernel module usage. The driver choice for USB depends on something like <usb-manufacturer-id>:<usb-product-id>.
Put some printfs into the kernel module to see where is fails. Use the DKMS build system for rebuilding the kernel module. There is a config file somewhere in Linux to blacklist/whitelist the kernel modules - useful to make sure that the right one is loaded.
That's what I was doing to fix a driver of an USB-serial device.
I have been tasked with setting up a development environment for an embedded platform. So far, I have set up a remote build host in NetBeans, which copies all of the source files to the target device, compiles them natively with the GNU toolchain on the device (g++, ld, etc.), and then runs the compiled binary and forwards stdout to the development machine that NetBeans is running on.
What I don't understand is: How does the binary on the build machine know where and when to start/stop if the breakpoints exist only in NetBeans? The build host only required ssh access and a compiling/linking toolchain, but somehow seems to communicate with NetBeans for debugging. A colleague of mine suggested it uses gdbserver, but I have not found any documentation on the NetBeans website about this package, and it is not installed on the build host (at least not from apt). How is NetBeans doing this?
GUI IDE's which use (or can be configured to use) a distinct command-line toolchain for compilation and debug typically do this by running each required toolchain program as a subprocess and interacting with it through standard streams. Essentially, the IDE would use gcc or gdb with the same textual interface used when running it in a terminal window. The IDE uses its knowledge of lines in the source file to configure breakpoints in gdb much as you would while running it by hand.
In your case, the IDE is configured to use a "remote host" for all of this, so instead of being invoked locally, the toolchain is controlled through as ssh session to the remote machine where both building and running occur.
Because the gdb debugger and the target program are running on the same computer, no gdbserver is required.
In the cases where gdb is too large for the target system, gdbserver is a small program which often gets cross-compiled for the target and loaded onto it. This serves as a compact little delegate which talks to the main gdb program running on a build machine via a serial or network connection and performs the raw interaction with processor, memory, and running program on behalf of gdb.
Another possibility is that the gdbserver role is held by a helper program running on the same machine as gdb which instead commands something like a JTAG debug adapter to interact with the target hardware at a lower level. In this case however, the helper program implementing the gdbserver protocol is not usually called "gdbserver" but instead has an implementation specific name, for example openocd.
gdb runs on the target machine. Only communication with gdb (commands etc) goes via net to your local machine. Read gdb documentation if need to know more/
You can do exactly the same - just open the remote terminal , run gdbserver, start gdb and you are done :)
I am attempting to use GDB to debug a remote target over a serial line on a windows box using MinGW. The target remote command GDB expects a path to a device driver (e.g. /dev/ttyS0) in order to connect to the remote target. There are 4 properly functioning serial ports on my machine, but they don't seem to be visible from MinGW. Is there a way to install them, or is this just not possible in the self proclaimed minimalist MinGW?
I did some searching on MinGW, Google, and here and wasn't able to find anything relevant.
Per #J.J Hakala com ports are just named com1, com2, etc in windows. They are in the root directory so ./com1 works as well. There is no need to install drivers.
I'm developing a program for a specific environment. That means it needs to run on the OS and compile using its compiler. I have a different environment at home (Windows 8) is there a way Netbeans can be used to connect to the target environment and use its compiler? It is enabled for remote login.
So basically right now I write code on my home computer, connect using Putty to the target computer, copy the source code over, compile it and run it. I'm trying to simplyfy this process so I only have to use Netbeans.
Why don't I just get same compiler and do everything locally? The target computer is running Linux and the program has a lot of system calls.
I know Aptana has a simillar feature, but Aptana is so crappy in general I don't want to use it.
Let me know if my question doesn't make sense and I'll try and reword it.
Yes, you can do remote development in NetBeans. It's described in its Help subsystem: