debugging linux kernel on arm926ejs target

anyone successfully debugged linux kernel via openocd + gdb pls read on:

greetings,

I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
zImage, this image boots properly via u-boot-1.1.6, however I simply
failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger. is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?

details:
1. let u-boot start the board;
2. I get the u-boot command prompt:

# bdinfo
      arch_number = 0x00000648
      env_t       = 0x00000000
      boot_params = 0x30000100
      DRAM bank   = 0x00000000
      -> start    = 0x30000000
      -> size     = 0x04000000
      DRAM bank   = 0x00000001
      -> start    = 0x38000000
      -> size     = 0x04000000
      ethaddr     = 00:40:5C:26:0A:5B
      ip_addr     = 192.168.3.5
      baudrate    = 115200 bps

3. halt the target via openocd/telnet;
4. cd to root directory of linux source code and issue:
gdb vmlinux
GNU gdb (GDB) 6.8.50.20090417
Copyright (C) 2009 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 "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb)

5.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0xc3e01874 in ?? ()
0xc3e01874: ldr r3, [r0, #16]
(gdb)

6.
(gdb) set remote hardware-breakpoint-limit 2
(gdb) set remote hardware-watchpoint-limit 2

7.
(gdb) load
Loading section .init, size 0x7b000 lma 0xc0008000 Loading section .text, size 0x2bb618 lma 0xc0083000 Loading section __ksymtab, size 0x4a58 lma 0xc033f000 Loading section __ksymtab_gpl, size 0x1360 lma 0xc0343a58 Loading section __ksymtab_gpl_future, size 0x18 lma 0xc0344db8 Loading section __ksymtab_strings, size 0xcab7 lma 0xc0344dd0 Loading section __param, size 0x654 lma 0xc0351888 Loading section .data, size 0x21538 lma 0xc0352000 Start address 0xc0008000, load size 3582507
Transfer rate: 35 KB/sec, 15922 bytes/write.
(gdb)

8. if I do continue (gdb) c, then I don't see any output on the serial console (as normally do during zImage booting process!)

where I'm messing up? or how should I get on with debugging the linux kernel at jtag level?

thanks,
ferar

So writable memory is at 0x30000000.

But gdb is loading the kernel at 0xc0008000.

This is quite a normal thing to do, because the vmlinux is linked to execute from 0xc0008000. This is the _virtual_ address, which is where the kernel expects to be running once basic services such as the MMU are initialized.

This initialization is done by the early part of the kernel, which given the above SDRAM settings, the kernel will expect to be loaded and executed at physical 0x30008000, not its link-time virtual address of 0xc0008000.

I don't do any debugging of kernels via gdb, so I couldn't tell you how to persuade gdb to load the kernel at a different address to that which it's linked for. However, relinking the kernel for 0x30008000 is definitely the wrong answer, and will result in something that also doesn't work.

I think you need to consult with the openocd folk to discuss how to debug a Linu kernel with their debugging solution.

Hi,

I am not sure how opencd works, but when we do debugging with bdi2000/gdb, we do by

a. load kernel using u-boot.

b. from bdi/telnet 'h' to halt, and set the break point (bi <addr>)to whatever symbol we have to stop. we use the address listed in the symbol table. then say 'go' to resume u-boot.

c. in u-booot, say bootm <addr> to boot. The kernel has to stop where the breakpoint has been put. On bdi/telnet, it will say something like "target has entered debug mode"

d. then use gdb and connect the target (target remote bdi-ip:portno) and gdb can list the code where the current breakpoint is active.

Regards,
Madhu