debug linux kernel on BeagleBoard XM with openOCD Flyswatter2 and insight debugger

GoogleGroups
1

I tried to debug linux kernel on Beagleboard XM with insight and flyswatters2. After I run arm-linux-gnueabi-insight vmlinux, I see the kernel is downloaded to the target via jtag flyswatter2. When it is done, a message box “Make breakpoint pending on future shared library load?” is popped up. If I click “Yes”, the insight would crash, otherwise I stop at header.S, then step, but it hangs at “beq __error_a” here is from gdb window

0x40200fa0 in ?? ()
Loading section .note.gnu.build-id, size 0x24 lma 0x0
Loading section .init, size 0x2bc96 lma 0x80008000
Loading section .text, size 0x5c6a88 lma 0x80034000
Loading section .rodata, size 0x847 lma 0x805fb000
Loading section .builtin_fw, size 0x30 lma 0x805fb848
Loading section __ksymtab, size 0x6310 lma 0x805fb878
Loading section __ksymtab_gpl, size 0x3818 lma 0x80601b88
Loading section __kcrctab, size 0x3188 lma 0x806053a0
Loading section __kcrctab_gpl, size 0x1c0c lma 0x80608528
Loading section __ksymtab_strings, size 0x1608d lma 0x8060a134
Loading section __param, size 0xe3c lma 0x806201c4
Loading section .data, size 0x4a980 lma 0x80622000
Start address 0x80008000, load size 6697150
Transfer rate: 10 KB/sec, 16021 bytes/write.

Breakpoint 3, stext () at arch/arm/kernel/head.S:79
Current language:  auto; currently asm

(gdb) n
(gdb) n
(gdb) b kernel_init
Breakpoint 4 at 0x800089c8: file init/main.c, line 312.

(gdb) n
2

Hi,

My attempts to use openocd + flyswatter to debug a kernel failed as well [1] and I neither get any kind of useful help from the OpenOCD folds nor from tincantools.

All the instructions I came across are either outdated or do not even attempt to debug a kernel.

Debugging u-boot seems to work, but as soon as we enter the beautiful world of virtual vs. physical memory things start to break so instead of buying many flyswatters I bought a few BDIs, which work for kernel debugging.

This is how I managed to do some debugging in u-boot:

cat /home/student/beagle-xm/u-boot/include/configs/omap3_beagle.h | grep CONFIG_SPL_TEXT_BASE
#define CONFIG_SPL_TEXT_BASE 0x40200800

telnet localhost 4444
amdm37x_dbginit dm37x.cpu
reset halt
bp 0x402009cc 4 hw
bp
poll
resume
when the breakpoint is hit remove it
rbp 0x402009cc
connect with gdb

arm-linux-gnueabi-gdb /home/student/beagle-xm/u-boot-build-mainline-student-v2013.04/spl/u-boot-spl
we should be on a breakpoint from the flyswatter
issue the following commands in gdb
target remote localhost:3333
info break
break __udelay
c
c
disable 1
info break

3

Hi Robert,

Which version of kernel works for BDI, but not flyswatter2?

Kind Regards

Kai

4

Hi,

Hi Robert,

Which version of kernel works for BDI, but not flyswatter2?

The problem is not the kernel version. I tried with various versions. All of them work with the BDI and don’t work with flyswatter2/OpenOCD.

Maybe with some ancient version of OpenOCD and patches it might work, but I did not find any version, which worked for me. [1]

[1] http://thread.gmane.org/gmane.comp.debugging.openocd.devel/23131

Regards,

Robert

5

Hi Kai,

I use kgdg/gdb to debug the linux kernel and it works really well,
in fact, its one of the things I love most about my beagleboard is the ability to debug the kernel.

I compile the beagleboard kernel with kgdb support enabled and run gdb on my laptop to debug the kernel.

I can set breakpoints and single step through the kernel , I recommend this approach.

Regards,

Scott.

6

Hi Scott/Kai,

I use kgdg/gdb to debug the linux kernel and it works really well,
in fact, its one of the things I love most about my beagleboard is the ability to debug the kernel.

Yes this works indeed, but being a software only solution it’s a bit limited. What I mean is with a JTAG device you can really stop hardware blocks like timers. You can’t do this with software. This means that for real low level software like manipulating registers I typically stay away from kdb/kgdb.

On the other hand to find out where the kernel oopsed kdb/kgdb are quite helpful. BTW ftdump (the one built into kdb) does not seem to work at the moment on the beagle-xm.

Other debugging alternatives could be kprobes and friends.

Kai if you tell us in more detail what you are trying to debug maybe we could help a bit more here.

Regards,

Robert

7

Other debugging alternatives could be kprobes and friends.

Kai if you tell us in more detail what you are trying to debug maybe we could help a bit more here.

Regards,

Robert

Hi Robert,

I tried to debug 2.6.39. Once Insight debugger downloading is finished, the debugger hangs, Here is openOCD debug message (-d 3)

Debug: 664969 1504955 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee100e15
Debug: 664970 1504957 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee070f35
Debug: 664971 1504959 breakpoints.c:309 breakpoint_free(): free BPID: 0 → 0
Debug: 664972 1504959 gdb_server.c:2019 gdb_input_inner(): received packet: ‘Z0,80008000,4’
Debug: 664973 1504959 gdb_server.c:1374 gdb_breakpoint_watchpoint_packet(): -
Debug: 664974 1504959 cortex_a.c:2155 cortex_a8_read_memory(): Reading memory at address 0x80008000; size 4; count 1
Debug: 664975 1504959 cortex_a.c:2106 cortex_a8_read_phys_memory(): Reading memory at real address 0x80008000; size 4; count 1
Debug: 664976 1504961 cortex_a.c:2304 cortex_a8_write_memory(): Writing memory at address 0x80008000; size 4; count 1
Debug: 664977 1504961 cortex_a.c:2308 cortex_a8_write_memory(): Writing memory to address 0x80008000; size 4; count 1
Debug: 664978 1504961 cortex_a.c:2200 cortex_a8_write_phys_memory(): Writing memory to real address 0x80008000; size 4; count 1
Debug: 664979 1504965 cortex_a.c:462 cortex_a8_write_dcc(): write DCC 0x80008000
Debug: 664980 1504965 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee100e15
Debug: 664981 1504967 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee070f35
Debug: 664982 1504969 breakpoints.c:106 breakpoint_add_internal(): added software breakpoint at 0x80008000 of length 0x00000004, (BPID: 1)
Debug: 664983 1504971 gdb_server.c:2019 gdb_input_inner(): received packet: ‘c’
Debug: 664984 1504971 target.c:1294 target_call_event_callbacks(): target event 5 (gdb-start)
Debug: 664985 1504971 gdb_server.c:1342 gdb_step_continue_packet(): -
Debug: 664986 1504971 gdb_server.c:1351 gdb_step_continue_packet(): continue
Debug: 664987 1504971 target.c:1294 target_call_event_callbacks(): target event 3 (resume-start)
Debug: 664988 1504971 target.c:1615 target_free_all_working_areas_restore(): freeing all working areas
Debug: 664989 1504971 cortex_a.c:957 cortex_a8_internal_restore(): resume pc = 0x80008004
Debug: 664990 1504971 cortex_a.c:462 cortex_a8_write_dcc(): write DCC 0x800001d3
Debug: 664991 1504971 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee100e15
Debug: 664992 1504973 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xe12ff000
Debug: 664993 1504975 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee070f95
Debug: 664994 1504977 cortex_a.c:1339 cortex_a8_restore_context():
Debug: 664995 1504979 cortex_a.c:462 cortex_a8_write_dcc(): write DCC 0x800001d3
Debug: 664996 1504979 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee100e15
Debug: 664997 1504981 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xe12ff000
Debug: 664998 1504983 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee070f95
Debug: 664999 1504985 cortex_a.c:462 cortex_a8_write_dcc(): write DCC 0x80008004
Debug: 665000 1504985 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee100e15
Debug: 665001 1504987 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xe1a0f000
Debug: 665002 1504989 arm_dpm.c:227 dpm_write_reg(): WRITE: pc, 80008004
Debug: 665003 1504989 cortex_a.c:462 cortex_a8_write_dcc(): write DCC 0x00000002
Debug: 665004 1504989 cortex_a.c:219 cortex_a8_exec_opcode(): exec opcode 0xee100e15
Debug: 665005 1504991 arm_dpm.c:227 dpm_write_reg(): WRITE: r0, 00000002
Debug: 665006 1504999 target.c:1294 target_call_event_callbacks(): target event 2 (resumed)
Debug: 665007 1504999 cortex_a.c:1097 cortex_a8_resume(): target resumed at 0x80008004
Debug: 665008 1504999 target.c:1294 target_call_event_callbacks(): target event 4 (resume-end)

Sometimes, it stops at the entry of header.S, I can step to __enable_mmu, then it hangs.

Kind Regards

Kai

8

Hi,

I tried to debug 2.6.39. Once Insight debugger downloading is finished, the debugger hangs, Here is openOCD debug message (-d 3)

As I told you before I did not manage to get openOCD/flyswatter 2 to work for kernel debugging. Similar to my experiments it’s freaking out when the MMU is turned on.

What I still don’t understand is which problem you are trying to solve. Do you just want to debug a Linux kernel for the fun of it or do you have a specific problem and need to debug it somehow?

If your problem is that you want to make openOCD/flyswatter 2 work for the beagle-xm you might want to try the openOCD mailing list [1]

[1] http://openocd.sourceforge.net/discussion/mailing-lists/

Regards,

Robert