[not solved yet] debugging linux kernel on arm926ejs target

[not solved yet] debugging linux kernel on arm926ejs target

[f. achkar]

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

[not solved yet] debugging linux kernel on arm926ejs target

[Russell King - ARM Linux]

On Thu, May 27, 2010 at 11:18:41AM -0400, f. achkar wrote:
>       DRAM bank   = 0x00000000
>       -> start    = 0x30000000
>       -> size     = 0x04000000
>       DRAM bank   = 0x00000001
>       -> start    = 0x38000000
>       -> size     = 0x04000000

So writable memory is at 0x30000000.

> (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.

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.

[not solved yet] debugging linux kernel on arm926ejs target

[Madhu]

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


On 05/27/2010 08:48 PM, f. achkar wrote:
> 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
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>