From: "Robert Cragie" <rcc@jennic.com>
To: <sid@sources.redhat.com>
Subject: Trying to run on pid7t board
Date: Wed, 21 Aug 2002 09:24:00 -0000 [thread overview]
Message-ID: <NDBBLOIOMLKELOJBAPAGEEHNCOAA.rcc@jennic.com> (raw)
Hi,
I have got SID via CVS (on 9th August 2002 about 1000 GMT) and built and
installed it fine on Redhat Linux 6.1. I have built a simple test using
eCos, using the pid target. I am invoking sid as follows:
arm-elf-sid --board=pid7t --verbose -EL --gdb=2000
I then connect to it using gdb (insight 5.0), and connect successfully to
the target. I then download the test, and inspect memory at 0x8000, no
problem, it's there. However, when I start to run, it hits the breakpoint I
have set, but I notice all the code has vanished at 0x8000, and it's
executing 0x00000000 each time. Any idea what's going on?
Here's the output (between <log></log>) from sid after downloading. I am
suspicious of the 'flush_i_cache' line - could this be flushing 0 into the
program space?:
<output from sid...>
process_set_reg 15 = [40 80 0 0 ]
<gdbserv_data_packet:Z>
add_breakpoint type 0 addr 77740 length 4
<gdbserv_data_packet:Z>
add_breakpoint type 0 addr 33992 length 4
<gdbserv_data_packet:H>
<target_packet>
<gdbserv_data_packet:c>
flush_i_cache <**** I am suspicious of this.
continue_program
target_power 1
Target scheduler 0 enabled==0
Host scheduler 0 yielded==1
trapstop_handler
target_power 0
Target scheduler 0 enabled==1
Host scheduler 0 yielded==0
<gdbserv_fromtarget_break RUNNING>
process_get_exp_regs 7 11 13 14 15 25 bytes=24
<gdbserv_data_packet:m>
process_get_mem addr=33976 len=4
<gdbserv_data_packet:z>
remove_breakpoint type 0 addr 77740 length 4
<gdbserv_data_packet:z>
remove_breakpoint type 0 addr 33992 length 4
<gdbserv_data_packet:m>
process_get_mem addr=32768 len=128
<gdbserv_data_packet:g>
process_get_regs
num_regs=26 bytes=168
<gdbserv_data_packet:m>
process_get_mem addr=32768 len=128
<gdbserv_data_packet:k>
exit_program
target_power 0
Target scheduler 0 enabled==0
Host scheduler 0 yielded==1
<gdbserv_fromtarget_break BROKEN>
socketio: ieof1
gdb: disconnect
<gdbserv_fromclient_detach EXITING>
process_detach
target_power 0
Target scheduler 0 enabled==0
Host scheduler 0 yielded==1
main loop ended after 47041 iterations.
main loop starting.
socketio: using fd 3
socketio: server at 0.0.0.0:2000
target_power 0
Target scheduler 0 enabled==0
Host scheduler 0 yielded==1
</output from sid...>
Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
http://www.jennic.com Tel: +44 (0) 114 281 2655
next reply other threads:[~2002-08-21 16:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-21 9:24 Robert Cragie [this message]
2002-08-21 9:35 ` Frank Ch. Eigler
2002-08-21 11:15 ` Robert Cragie
2002-08-21 11:31 ` Frank Ch. Eigler
2002-08-22 4:48 ` Robert Cragie
2002-08-22 6:22 ` Frank Ch. Eigler
2002-08-22 7:11 ` Ben Elliston
2002-08-22 10:09 ` Robert Cragie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=NDBBLOIOMLKELOJBAPAGEEHNCOAA.rcc@jennic.com \
--to=rcc@jennic.com \
--cc=sid@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).