I got vmlinux.uimg and vmlinux from my friend. The vmlinux is build with Linux version 4.14.10. I have two machines:
target (arm 32 bit architecture) and
host (x86 architecture)
Both systems are connected with wire, port numbers are /dev/ttySAC3 and /dev/ttyUSB0 respectively. Target boot up by reading image file vmlinux.uimg from sd card. I want to debug this vmlinux from my host machine.
The steps I am following are:
Start minicom in host.
Type
echo ttySAC3,115200 > /sys/module/kgdboc/parameters/kgdboc in minicom.
I am getting "KGDB: Registered I/O driver kgdboc".
Type
echo g >/proc/sysrq-trigger in minicom
I am getting "sysrq DEBUG and Entering KGDB".
Close minicom.
Go to vmlinux folder through terminal in host machine.
Type
gdb vmlinux
[Note: this gdb I am using is 7.10 version for arm]
In GDB type
target remote /dev/ttyUSB0
It give me a message
Remote debugging using /dev/ttyUSB0 0xc0d14f5 in sysrq_dbg_op()
In GDB type
b do_mmap_pgoff
I am getting a message
breakpoint 1 at xxxx: do_map_pgoff (4 location)
In GDB type
cont
This gives me a message
Continuing.
and then does nothing..
The problems:
GDB continue is not working as expected. I am expecting last step(9) to continue with target restart and hit the break point instead it is getting crash.
GDB step and next are not working as expected. Single stepping until exit from sysrq_dbg_op() which has no line number information. "Warning: invalid remote reply".
GDB 'run' is also not working. It display a message "The remote target does not support run"
How can I call a module on my target on which I have put breakpoint as I can not use minicom and gdb concurrently.
What all steps I should follow after I freeze the kernel.
What is wrong in this process?
Related
I want to run linux on qemu to test some system design, I use default config for x86_64, I found that I must append "console=ttyS0" to boot arguments so that I can get kernel message, without the ttyS0 I can't get any output.
So I want to check qemu's device tree, another strange thing is that I found there is no device-tree directory under /sys/fireware.
I want to check following question:
why we need "console=ttyS0" to get output ?
doesn't x86 use device-tree during booting ?
Not long ago CLion added support for Remote GDB debugging and I'm trying to set it up with Seggers's J-Link GDB server.
My setup:
VM VirtualBox running Ubuntu 16.04
J-Link drivers: V6.10
Target chip: nRF51 (ARM Cortex M0)
CLion 2016.2.2
I usually work in windows, but as CLion doesn't support remote GDB in windows I'm trying to make it work running Ubuntu in VirtualBox. I configured the debugger in CLion like shown in the image with a little help from the blog in the link above. The arguments I have used are based on the J-Link documentation (Document: UM08001) and some guessing.
GDB server setup
My problem is that when running the debugger the process just stops and CLion's console outputs:
"Could not connect to target. Please check power, connection and
settings."
I have tried to run JLinkGDBServer from the terminal and then I get as far as this:
/usr/bin/JLinkGDBServer -device nrf51422_xxAC -if swd -speed 1000 -endian little
SEGGER J-Link GDB Server V6.10 Command Line Version
JLinkARM.dll V6.10 (DLL compiled Sep 14 2016 16:46:16)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: nrf51422_xxAC
Target interface: SWD
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09
Hardware: V1.00
S/N: 681666518
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Does anyone have a clue of what I'm doing wrong?
You're probably confusing GDB server and GDB itself. Those are GDB options that should be set in the GDB Remote Debug Configuration in CLion, not GDB server settings.
That is, you first run JLinkGDBServer manually, for example, from terminal, just as you've done already, and leave it waiting for GDB to attach. At this moment one should notice the connection port:
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Then edit your GDB Remote Debug Configuration in CLion to use the host GDB (most likely /usr/bin/gdb in your case, install it using sudo apt install gdb if necessary), and use the port mentioned above as part of the "target remote" string:
GDB: /usr/bin/gdb
"target remote" args: :2331
Notice the preceding colon in front of the port. This is a shorthand for connecting to localhost using TCP. Just in case, the explicit form is tcp:localhost:2331.
Now you can start the debug session. CLion will start the configured host GDB, GDB communicates to JLinkGDBServer through the specified TCP connection, and finally the GDB server chats with your device.
I'm having problems trying to setup dev env for STM32F4 Discovery board in Windows.
I have installed all required files (GCC for ARM, Windows Build Tools, Eclipse Plugin) and I'm getting this error when trying to start OpenOCD debugging:
Missing mandatory configuration. Fill-in the 'Config options:' field in the Debugger tab.
This is my debug config screen:
And this is the error which I get when I try to start it (and build success message):
openocd must be told what kind of board it should talk to
http://gnuarmeclipse.github.io/debug/openocd/#create-the-debugger-configuration
the only field that usually requires attention is the OpenOCD Setup
Other options:, where you should add one or more configuration
scripts; for example, for the STM32F4DISCOVERY board, the field should
read -f board/stm32f4discovery.cfg
I'm running a small test program on an embedded Linux target (a Freescale i.MX25), which I'd like to debug using GDB. I connect to the system using an FTDI USB-RS232 cable through am Ubuntu VM. GDBserver is installed on the target. I do not have Ethernet or USB support on the target, so I'm trying to use GDB over serial.
When I log into the target using Minicom, I get:
login[1691]: root login on 'ttymxc0'
which I presume means that the console is using ttymxc0. Then, I try to start GDBserver listening for connections from the VM to the test program, residing in /home:
$ cd /home
$ gdbserver /dev/ttymxc0 test
which gives the output (repeatedly):
Remote debugging using /dev/ttymxc0
readchar: Socket operation on non-socket
Remote side has terminated connection. GDBserver will reopen the connection
Is this an error in the way I'm trying to use GDBserver, or something else? Is there another way to debug the program?
You can not use ttymxc0 for two things at the same time (serial console and serial gdb). Disable the getty on that serial line and replace it by the gdbserver.
I am trying to run a remote mathematica kernel between two macs.
Under Kernel Configuration Options
For kernel program I have:
/Applications/Mathematica.app/Contents/MacOS/MathKernel
The arguments of MLOpen:
-LinkMode Listen
-LinkProtocol TCPIP
-LinkOptions MLDontInteract
The launch command is:
java -jar mathssh username#xxxxxx.dynamic.uiowa.edu /usr/local/bin/math -mathlink -LinkMode
Connect -LinkProtocol TCPIP -LinkName "linkname" -LinkHost ipaddress
When i use this remote kernel (for instance 2+2 does not give a result) I get the error message:
"The kernel Thomas Machine failed to connect to the front end. (Error = MLECONNECT). You should try running the kernel connection outside the front end."
It seems that Mathematica is not even opening on the remote machine since I used "top" and do not see it running after I start the remote kernel.
Any help would be greatly appreciated.
I just tried this with 8.0.1 -- here's my config (with bogus machine/user names):
In particular the /usr/local/bin/math looks suspicious. You generally shouldn't need to use the advanced settings.
Drop to a command line and try:
ssh username#xxxxxx.dynamic.uiowa.edu /usr/local/bin/math
and see if you get a Mathematica prompt and can evaluate 1+1 there.