debug board setup / turning aux led on very late in the suspend path

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

debug board setup / turning aux led on very late in the suspend path

Timo Juhani Lindfors
Hi,

I used the debug board today after a long pause so I thought I might
want to document the steps I had to do to get it to work:

1) boot openmoko normally
2) (openmoko) sudo /etc/init.d/watchdog stop
3) (openmoko) sudo killall wd_keepalive
4) (openmoko) sudo sh -c 'echo -n V > /dev/watchdog'2) connect debug board to PC
5) connect debug board to openmoko
6) (PC) cat > openocd.cfg <<EOF

interface ft2232
ft2232_device_desc "Debug Board for Neo1973 A"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x1457 0x5118

source [find target/samsung_s3c2440.cfg]

reset_config trst_and_srst

#jtag_khz 0

gdb_port 3333
tcl_port 6666
telnet_port 4444
EOF
7) (PC) sudo openocd
8) (PC) run arm-linux-gnueabi-gdb
9) (gdb) target remote localhost:3333
10) (gdb) continue
11) (gdb) ctrl-c
12) (gdb) monitor gdb_breakpoint_override hard
13) (gdb) monitor arm7_9 dbgrq enable
14) (gdb) continue
15) (gdb) ctrl-c
16) (gdb) break s3c_pm_save_gpios
17) (gdb) continue
18) (openmoko) sudo sh -c 'echo mem > /sys/power/state'
19) (gdb) define xsi
si
x/3i $pc
end
20) (gdb) single step the suspend process with this new "xsi" command

Version information:
PC is debian gnu/linux stable with openocd 0.4.0-1+nmu1 running from a
debian unstable chroot

openmoko is gta02v5 running debian unstable with 2.6.34 kernel
branched from radekp's qtmoko27 branch

debug board is version 2


My original goal was to turn the AUX led ON very late in the suspend
path so that I could distinguish between failed and working suspend by
looking at the led. I assumed I could just add 0x4 to 0x56000014 but
for some reason even trying to read from this address apparently
causes a fault or something:


(gdb) xsi
0xc0035bac in s3c_cpu_save ()
0xc0035bac <s3c_cpu_save+28>:   ldr     r0, [pc, #8]    ; 0xc0035bbc <resume_with_mmu+4>
0xc0035bb0 <s3c_cpu_save+32>:   ldr     r0, [r0]
0xc0035bb4 <s3c_cpu_save+36>:   mov     pc, r0
(gdb) xsi
0xc0035bb0 in s3c_cpu_save ()
0xc0035bb0 <s3c_cpu_save+32>:   ldr     r0, [r0]
0xc0035bb4 <s3c_cpu_save+36>:   mov     pc, r0
0xc0035bb8 <resume_with_mmu>:   pop     {r4, r5, r6, r7, r8, r9, r10, r11, r12, pc}
(gdb)
0xc0035bb4 in s3c_cpu_save ()
0xc0035bb4 <s3c_cpu_save+36>:   mov     pc, r0
0xc0035bb8 <resume_with_mmu>:   pop     {r4, r5, r6, r7, r8, r9, r10, r11, r12, pc}
0xc0035bbc <resume_with_mmu+4>: eorsgt  r11, lr, r0, lsr r8
(gdb)
0xc0032860 in s3c2410_cpu_suspend ()
0xc0032860 <s3c2410_cpu_suspend>:       mov     r4, #1442840576 ; 0x56000000
0xc0032864 <s3c2410_cpu_suspend+4>:     ldr     r5, [r4, #20]
0xc0032868 <s3c2410_cpu_suspend+8>:     orr     r5, r5, #4      ; 0x4
(gdb)
0xc0032864 in s3c2410_cpu_suspend ()
0xc0032864 <s3c2410_cpu_suspend+4>:     ldr     r5, [r4, #20]
0xc0032868 <s3c2410_cpu_suspend+8>:     orr     r5, r5, #4      ; 0x4
0xc003286c <s3c2410_cpu_suspend+12>:    str     r5, [r4, #20]
(gdb) p $r4
$3 = 1442840576
(gdb) p/x $r4
$4 = 0x56000000
(gdb) xsi
  C-c C-cHalt timed out, wake up GDB.


What am I missing here?


Reply | Threaded
Open this post in threaded view
|

Re: debug board setup / turning aux led on very late in the suspend path

Vasily Khoruzhick
On Thursday 04 November 2010 16:09:32 Timo Juhani Lindfors wrote:

> Hi,
>
> I used the debug board today after a long pause so I thought I might
> want to document the steps I had to do to get it to work:
>
> 1) boot openmoko normally
> 2) (openmoko) sudo /etc/init.d/watchdog stop
> 3) (openmoko) sudo killall wd_keepalive
> 4) (openmoko) sudo sh -c 'echo -n V > /dev/watchdog'2) connect debug board
> to PC 5) connect debug board to openmoko
> 6) (PC) cat > openocd.cfg <<EOF
>
> interface ft2232
> ft2232_device_desc "Debug Board for Neo1973 A"
> ft2232_layout "jtagkey"
> ft2232_vid_pid 0x1457 0x5118
>
> source [find target/samsung_s3c2440.cfg]
>
> reset_config trst_and_srst
>
> #jtag_khz 0
>
> gdb_port 3333
> tcl_port 6666
> telnet_port 4444
> EOF
> 7) (PC) sudo openocd
> 8) (PC) run arm-linux-gnueabi-gdb
> 9) (gdb) target remote localhost:3333
> 10) (gdb) continue
> 11) (gdb) ctrl-c
> 12) (gdb) monitor gdb_breakpoint_override hard
> 13) (gdb) monitor arm7_9 dbgrq enable
> 14) (gdb) continue
> 15) (gdb) ctrl-c
> 16) (gdb) break s3c_pm_save_gpios
> 17) (gdb) continue
> 18) (openmoko) sudo sh -c 'echo mem > /sys/power/state'
> 19) (gdb) define xsi
> si
> x/3i $pc
> end
> 20) (gdb) single step the suspend process with this new "xsi" command
>
> Version information:
> PC is debian gnu/linux stable with openocd 0.4.0-1+nmu1 running from a
> debian unstable chroot
>
> openmoko is gta02v5 running debian unstable with 2.6.34 kernel
> branched from radekp's qtmoko27 branch
>
> debug board is version 2
>
>
> My original goal was to turn the AUX led ON very late in the suspend
> path so that I could distinguish between failed and working suspend by
> looking at the led. I assumed I could just add 0x4 to 0x56000014 but
> for some reason even trying to read from this address apparently
> causes a fault or something:
>
>
> (gdb) xsi
> 0xc0035bac in s3c_cpu_save ()
> 0xc0035bac <s3c_cpu_save+28>:   ldr     r0, [pc, #8]    ; 0xc0035bbc
> <resume_with_mmu+4> 0xc0035bb0 <s3c_cpu_save+32>:   ldr     r0, [r0]
> 0xc0035bb4 <s3c_cpu_save+36>:   mov     pc, r0
> (gdb) xsi
> 0xc0035bb0 in s3c_cpu_save ()
> 0xc0035bb0 <s3c_cpu_save+32>:   ldr     r0, [r0]
> 0xc0035bb4 <s3c_cpu_save+36>:   mov     pc, r0
> 0xc0035bb8 <resume_with_mmu>:   pop     {r4, r5, r6, r7, r8, r9, r10, r11,
> r12, pc} (gdb)
> 0xc0035bb4 in s3c_cpu_save ()
> 0xc0035bb4 <s3c_cpu_save+36>:   mov     pc, r0
> 0xc0035bb8 <resume_with_mmu>:   pop     {r4, r5, r6, r7, r8, r9, r10, r11,
> r12, pc} 0xc0035bbc <resume_with_mmu+4>: eorsgt  r11, lr, r0, lsr r8
> (gdb)
> 0xc0032860 in s3c2410_cpu_suspend ()
> 0xc0032860 <s3c2410_cpu_suspend>:       mov     r4, #1442840576 ;
> 0x56000000 0xc0032864 <s3c2410_cpu_suspend+4>:     ldr     r5, [r4, #20]
> 0xc0032868 <s3c2410_cpu_suspend+8>:     orr     r5, r5, #4      ; 0x4
> (gdb)
> 0xc0032864 in s3c2410_cpu_suspend ()
> 0xc0032864 <s3c2410_cpu_suspend+4>:     ldr     r5, [r4, #20]
> 0xc0032868 <s3c2410_cpu_suspend+8>:     orr     r5, r5, #4      ; 0x4
> 0xc003286c <s3c2410_cpu_suspend+12>:    str     r5, [r4, #20]
> (gdb) p $r4
> $3 = 1442840576
> (gdb) p/x $r4
> $4 = 0x56000000
> (gdb) xsi
>   C-c C-cHalt timed out, wake up GDB.
>
>
> What am I missing here?

Maybe I'm wrong, but you can't debug suspend/resume sequence via JTAG, as in
suspend ARM core is completely disabled.

Regards
Vasily

Reply | Threaded
Open this post in threaded view
|

Re: debug board setup / turning aux led on very late in the suspend path

Timo Juhani Lindfors
Vasily Khoruzhick <[hidden email]> writes:
>> What am I missing here?
>
> Maybe I'm wrong, but you can't debug suspend/resume sequence via JTAG, as in
> suspend ARM core is completely disabled.

Yes but that ldr instruction should not have caused suspend yet?

It should have executed a few more instructions before really entering
suspend?


Reply | Threaded
Open this post in threaded view
|

Re: debug board setup / turning aux led on very late in the suspend path

Timo Juhani Lindfors
In reply to this post by Timo Juhani Lindfors
Hi,

Timo Juhani Lindfors <[hidden email]> writes:
> 8) (PC) run arm-linux-gnueabi-gdb

That should be

8) (PC) run arm-linux-gnueabi-gdb vmlinux

> 0xc0032864 in s3c2410_cpu_suspend ()
> 0xc0032864 <s3c2410_cpu_suspend+4>:     ldr     r5, [r4, #20]
> 0xc0032868 <s3c2410_cpu_suspend+8>:     orr     r5, r5, #4      ; 0x4
> 0xc003286c <s3c2410_cpu_suspend+12>:    str     r5, [r4, #20]
> (gdb) p $r4
> $3 = 1442840576
> (gdb) p/x $r4
> $4 = 0x56000000
> (gdb) xsi
>   C-c C-cHalt timed out, wake up GDB.

And I guess this fails since leds are not mapped to that address under
linux.

0xc003311c in gta02_gpb_set ()
0xc003311c <gta02_gpb_set+100>: str     r2, [r3, #20]
0xc0033120 <gta02_gpb_set+104>: msr     CPSR_c, lr
0xc0033124 <gta02_gpb_set+108>: ldm     sp, {r4, r5, r6, r11, sp, pc}
(gdb) p/x $r3
$11 = 0xfb000000

shows that the normal LED driver accesses them at a different address.

Reply | Threaded
Open this post in threaded view
|

Re: debug board setup / turning aux led on very late in the suspend path

Timo Juhani Lindfors
Timo Juhani Lindfors <[hidden email]> writes:
> 0xc003311c in gta02_gpb_set ()
> 0xc003311c <gta02_gpb_set+100>: str     r2, [r3, #20]
> 0xc0033120 <gta02_gpb_set+104>: msr     CPSR_c, lr
> 0xc0033124 <gta02_gpb_set+108>: ldm     sp, {r4, r5, r6, r11, sp, pc}
> (gdb) p/x $r3
> $11 = 0xfb000000
>
> shows that the normal LED driver accesses them at a different address.

If I try to access the LED via this address very late in the suspend
code I avoid the crash but the LED is not turned on either:

(gdb) xsi
0xc003286c in s3c2410_cpu_suspend ()
0xc003286c <s3c2410_cpu_suspend+12>:    str     r5, [r4, #20]
0xc0032870 <s3c2410_cpu_suspend+16>:    ldr     r4, [pc, #92]   ; 0xc00328d4 <s3c2410_do_sleep+20>
0xc0032874 <s3c2410_cpu_suspend+20>:    ldr     r5, [pc, #92]   ; 0xc00328d8 <s3c2410_do_sleep+24>
(gdb) p/x $r5
$15 = 0x4
(gdb) p/x $r4
$16 = 0xfb000000

Maybe the GPIOs are set as inputs or something?