Using KGDB on SAMA5D2. kgdbwait not working

[gselabs]

I trying to use KGDB on SOM1-EK board without any luck. I have enabled all necessary options in the kernel config such as:

Code: Select all

CONFIG_GDB_SCRIPTS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y

and add the following to the kernel boot parameters

Code: Select all

kgdbwait kgdboc=ttyS0,115200

But the kernel doesn't wait at boot. It boots as usual. The following command also return nothing:

Code: Select all

~# cat  /sys/module/kgdboc/parameters/kgdboc

I wonder how I can use KGDB? What I am doing wrong? Is there a good manual/tutorial about using KGDB? I prefer to use it with Eclipse.

[gselabs]

~# echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc
KGDB: Registered I/O driver kgdboc
KGDB: Waiting for connection from remote gdb...

Works as expected, But I need to start KGDB at kernel start, so the problem is not solved yet.

[blue_z]

I trying to use KGDB on SOM1-EK board without any luck. I have enabled all necessary options in the kernel config such as:
...
and add the following to the kernel boot parameters

Code: Select all

kgdbwait kgdboc=ttyS0,115200

Since you enabled CONFIG_KGDB_SERIAL_CONSOLE, you need to also include ekgdboc in the kernel command line.

The order of certain parameters in the kernel command line is salient.
According to this guide, the "kgdbwait parameter should always follow the configuration parameter for the kgdb I/O driver."
IOW try

Code: Select all

kgdboc=ttyS0,115200 ekgdboc kgdbwait

However I have my doubts that this early interaction can work, since the tty driver is available only after it is initialized later in the boot sequence.
Maybe an implementation of an early console is needed.
You can use earlyprintk to see how far the kernel progresses before it breakpoints.

Regards

[gselabs]

I have tried the ekgdboc parameter without any luck...
Now I am trying to run the kgdb manually after boot with

Code: Select all

echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc

It triggers KGDB on the target but I can't connect to it from the host. Connection is very unreliable.
Here is what I got

Code: Select all

sergei@ub:~/git/aqc_embedded/rootfs_yocto/build-microchip/tmp/work/cube_som1_ek-poky-linux-gnueabi/linux-at91/local-30/build$ gdb-multiarch ./vmlinux 
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./vmlinux...done.
warning: File "/home/sergei/git/aqc_embedded/rootfs_yocto/build-microchip/tmp/work-shared/cube-som1-ek/kernel-source/scripts/gdb/vmlinux-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /home/sergei/git/aqc_embedded/rootfs_yocto/build-microchip/tmp/work-shared/cube-som1-ek/kernel-source/scripts/gdb/vmlinux-gdb.py
line to your configuration file "/home/sergei/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/sergei/.gdbinit".
For more information about this security protection see the
---Type <return> to continue, or q <return> to quit---
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) set remotebaud 115200
No symbol "remotebaud" in current context.
(gdb) set serial baud 115200
(gdb) set debug remote 1
(gdb) target remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Nak
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Nak
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Nak
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Packet qSupported (supported-packets) is supported
warning: unrecognized item "timeout" in "qSupported" response
Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Nak
Sending packet: $vMustReplyEmpty#3a...Nak
Sending packet: $vMustReplyEmpty#3a...Nak
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
(gdb) 

I connected to the SOM1-EK board via J10 USB-A MicroAB, J-Link-OB port. Every thing looks very strange... Each new attempt to run

Code: Select all

(gdb) target remote /dev/ttyACM0

gives me different number of different "errors" - usually Naks and time outs.

So, I wonder, is there examples of using KGDB on Microchip's evaluation boards? It seems that the task is pretty common - debug the kernel or kernel module. But there is no info about it at Microchip's WEB sites... How I can debug the kernel or kernel module?

Here is some useful info which is not solve my problem but may helps to others:
https://stackoverflow.com/questions/145 ... ild-kernel

Any help will be appreciated.

[gselabs]

So, some attempts look more successfull but also fail at some point:

Code: Select all

(gdb) target remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Ack
Packet received: 
Packet qSupported (supported-packets) is NOT supported
Sending packet: $vMustReplyEmpty#3a...Nak
Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Ack
Packet received: 
Sending packet: $Hg0#df...Nak
Sending packet: $Hg0#df...Nak
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qTStatus#49...Sending packet: $qTStatus#49...Nak
Sending packet: $qTStatus#49...Nak
Sending packet: $qTStatus#49...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Packet qTStatus (trace-status) is supported
Bogus trace status reply from target: timeout
(gdb) c
The program is not being run.
(gdb) 

I saw that some times the:

Code: Select all

~# echo g > /proc/sysrq-trigger

command had been mentioned.
But I can not run any thing on the target after i run the following:

Code: Select all

root@cube-som1-ek:~# echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc                                                                                          
KGDB: Registered I/O driver kgdboc                                                                                                                                     
KGDB: Waiting for connection from remote gdb...

[gselabs]

I tried many ways to bring KGDB to live, but nothing works for me. Also I found tha gdb-multiarch was configured for different target. I don't understand why in such case possible to

Code: Select all

set architecture arm

. The second problem which I found is that the KDBG in linux4sam repository (and may be in mainline one also) is possibly can't work with latest GDB release. There is not easy to understand which GDB release was tested with current version of ARM KDBG module. May be somebody can shed a lid to the problem?