Trying to run on pid7t board

Trying to run on pid7t board

[Robert Cragie]

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

Re: Trying to run on pid7t board

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Hi -

On Wed, Aug 21, 2002 at 05:24:50PM +0100, Robert Cragie wrote:
> [...]
> 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?

Yes, that is odd.  Can you tell me why you think it's executing 0x0?
You could show gdb's side of the conversation, either a console script,
or maybe even include packet traces as per `(gdb) set remote debug 3'.


> [...]
> I am suspicious of the 'flush_i_cache' line - could this be flushing 0
> into the program space?:
> [...]

I don't think so.  The only cache in the pid7t configuration is a little
instruction-decoding cache inside the CPU model, and flushing it just means
throwing it away.  The instruction memory should not be affected at all.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: Trying to run on pid7t board

[Robert Cragie]

> On Wed, Aug 21, 2002 at 05:24:50PM +0100, Robert Cragie wrote:
> > [...]
> > 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?
>
> Yes, that is odd.  Can you tell me why you think it's executing 0x0?
> You could show gdb's side of the conversation, either a console script,
> or maybe even include packet traces as per `(gdb) set remote debug 3'.

If I specify --trace-semantics in the sid command line I get the following:

0x8040: LDR_PRE_INC_IMM_OFFSET	gr[0]:=0x8048
0x8044: MOV_REG_IMM_SHIFT	pc:=0x8048
0x8048: LDR_PRE_INC_IMM_OFFSET	gr[0]:=0xb000020
0x804c: STR_PRE_INC_IMM_OFFSET	memory[0xb000020]:=0xb000020
0x8050: AND_REG_IMM_SHIFT
0x8054: AND_REG_IMM_SHIFT
0x8058: AND_REG_IMM_SHIFT
0x805c: AND_REG_IMM_SHIFT

...AND_REG_IMM_SHIFT looks like andeq r0,r0,r0 to me (i.e. NOP). I stepped
through the code and sure enough what happens is that indeed the first three
opcodes run OK, but when the fourth opcode is run, it screws up thereafter -
all the memory gets set to 0.

On the PID board, 'str r0,[r0]', where r0 is 0xb000020, changes the mapping
of the PID board mapping RAM to 0x0000000 instead of ROM - if the REMAP
board link (LK18) is in place. So it looks like the simulation of this is
doing something odd causing it to go wrong - I would expect it to just carry
on, as I would guess the software component of the simulation would have
already remapped (as a debug monitor on a real board would have), and once
this is done, it's done until the next reset.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655

Re: Trying to run on pid7t board

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

Hi -

On Wed, Aug 21, 2002 at 07:15:24PM +0100, Robert Cragie wrote:
> [...]
> If I specify --trace-semantics in the sid command line I get the following:
> 
> 0x8040: LDR_PRE_INC_IMM_OFFSET	gr[0]:=0x8048
> 0x8044: MOV_REG_IMM_SHIFT	pc:=0x8048
> 0x8048: LDR_PRE_INC_IMM_OFFSET	gr[0]:=0xb000020
> 0x804c: STR_PRE_INC_IMM_OFFSET	memory[0xb000020]:=0xb000020
> 0x8050: AND_REG_IMM_SHIFT
> 0x8054: AND_REG_IMM_SHIFT
> 0x8058: AND_REG_IMM_SHIFT
> 0x805c: AND_REG_IMM_SHIFT
> 
> ...AND_REG_IMM_SHIFT looks like andeq r0,r0,r0 to me (i.e. NOP). [...]

Yup.

> On the PID board, 'str r0,[r0]', where r0 is 0xb000020, changes the mapping
> of the PID board mapping RAM to 0x0000000 instead of ROM - if the REMAP
> board link (LK18) is in place. [...]

Aha.  The remapper is indeed involved, as is the eCos startup sequence.
It seems that after the access to 0xb000020, the 0x0-0xffff mapping window
into 0x4000000 disappears.  In such circumstances, the code can only work
if the running PC switches over to the ROM area (0x40008048).  In some
versions of eCos, this is forced by the first few instructions, apparently
not yours.

There are a couple of possible workarounds.  If you are positive that your
eCos application will run correctly on a board of interest, then you could
toggle sid's remapper setting (add "-normalmap" to the "--board" argument 
sublist as in "--board=pid7t-normalmap").  Other ways would involve tweaking
the eCos startup sequence, or the executable, or sid loading/startup.

Please be aware that in your given mode, sid is attempting to emulate a board
just after powerup.  If your application assumes that it's being loaded by
an already-running monitor, such mismatches need to be corrected some way.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: Trying to run on pid7t board

[Robert Cragie]

> Aha.  The remapper is indeed involved, as is the eCos startup sequence.
> It seems that after the access to 0xb000020, the 0x0-0xffff mapping window
> into 0x4000000 disappears.  In such circumstances, the code can only work
> if the running PC switches over to the ROM area (0x40008048).  In some
> versions of eCos, this is forced by the first few instructions, apparently
> not yours.

This would explain the slightly odd startup sequence of:

      ldr     r0,=10f
      mov     pc,r0
10:	ldr	r0,=MEM_RESET
	str	r0,[r0]

i.e. the second opcode just moves the pc to where it would have gone anyway.

> There are a couple of possible workarounds.  If you are positive that your
> eCos application will run correctly on a board of interest, then you could
> toggle sid's remapper setting (add "-normalmap" to the "--board" argument
> sublist as in "--board=pid7t-normalmap").  Other ways would involve tweak
ing
> the eCos startup sequence, or the executable, or sid loading/startup.

Adding the -normalmap argument worked - thanks. I will point this out on the
eCos mailing list, as the default sid flags for the RAM build won't work.
Next step is to try to work out why printf() doesn't work, however this
seems to be an eCos issue. However, while I'm here, can you tell me how the
serial ports work on the simulation (i.e. what happens when I write a
character), or point me at some appropriate docs.?

> Please be aware that in your given mode, sid is attempting to
> emulate a board just after powerup.  If your application assumes that it's
being loaded by
> an already-running monitor, such mismatches need to be corrected some way.

I think I misunderstood the way the gloss component works - I guess it's
more like an on-chip ICE than a debug monitor.

Thanks for your help

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655

Re: Trying to run on pid7t board

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

Hi -


On Thu, Aug 22, 2002 at 12:48:55PM +0100, Robert Cragie wrote:
> [...]
> Adding the -normalmap argument worked - thanks. I will point this out on the
> eCos mailing list, as the default sid flags for the RAM build won't work.

This may not concern (interest) the eCos guys.  SID can do a better job
of emulating the RAM startup environment that eCos expects.  This
"normalmap" option is just one possibility.  Another one is to actually
run a copy of RedBoot or cygmon or whatever on SID.  Then you can upload
your application via a simulated serial port, making it look to gdb etc.
much more like it was a real board.


> Next step is to try to work out why printf() doesn't work, however this
> seems to be an eCos issue. However, while I'm here, can you tell me how the
> serial ports work on the simulation (i.e. what happens when I write a
> character), or point me at some appropriate docs.?

For the pid7t configuration, sid models two uarts.  The arm-elf-sid script
can take options to let you tell it how you'd like these simulated uarts
to be connected to the real world.  This is done with more --board options.
For example "--board=pid7t-uart1:stdio-uart2:3000" would connect the
simulated uart1 to the simulator's console, and uart2 to a tcp (listening)
socket at port 3000.  One can also add a tk-based terminal window, or add
one after startup if using tksm.


> > Please be aware that in your given mode, sid is attempting to
> > emulate a board just after powerup.  If your application assumes that it's
> > being loaded by an already-running monitor, such mismatches need to be
> > corrected some way.
> 
> I think I misunderstood the way the gloss component works - I guess it's
> more like an on-chip ICE than a debug monitor.

I suspect that the sid gloss component proper (simulated system calls) is
not even used in these configurations.  If you mean the usual simulator
debugging interface, then yes, that's right.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Trying to run on pid7t board

[Ben Elliston]

>>>>> "FChE" == Frank Ch Eigler <fche@redhat.com> writes:

  >> I think I misunderstood the way the gloss component works - I guess it's
  >> more like an on-chip ICE than a debug monitor.

  FChE> I suspect that the sid gloss component proper (simulated system calls) is
  FChE> not even used in these configurations.  If you mean the usual simulator
  FChE> debugging interface, then yes, that's right.

The pid7t model may connect in an ARM Angel monitor component, but I
don't recall off hand.

Ben

RE: Trying to run on pid7t board

[Robert Cragie]

> This may not concern (interest) the eCos guys.  SID can do a better job
> of emulating the RAM startup environment that eCos expects.  This
> "normalmap" option is just one possibility.  Another one is to actually
> run a copy of RedBoot or cygmon or whatever on SID.  Then you can upload
> your application via a simulated serial port, making it look to gdb etc.
> much more like it was a real board.

OK, I won't mention it to the eCos guys. I see the memory components can
have an image file, allowing a boot monitor to be there on 'power up'.

> For the pid7t configuration, sid models two uarts.  The arm-elf-sid script
> can take options to let you tell it how you'd like these simulated uarts
> to be connected to the real world.  This is done with more
> --board options.
> For example "--board=3Dpid7t-uart1:stdio-uart2:3000" would connect the
> simulated uart1 to the simulator's console, and uart2 to a tcp (listening)
> socket at port 3000.  One can also add a tk-based terminal window, or add
> one after startup if using tksm.

With some further juggling of eCos configuration, I have got it printing to
the gdb console (-uart1:gdb), to the console sid was run from (-uart1:stdio)
and the tksm tty window. Excellent! Now I am having problems with the
timer-related calls (cyg_thread_delay() etc.) - I notice in the list this
was also seen by Cristiano Pereira (04-Mar-02). I have done some debugging,
and timer interrupt seems to fire once, then a data_abort exception is
thrown a bit later; looks like the pc was 0xe59d0044. Ho hum. I will try to
get to the bottom of what is going on - if anyone has any ideas, I'd
appreciate them.

> I suspect that the sid gloss component proper (simulated system calls) is
> not even used in these configurations.  If you mean the usual simulator
> debugging interface, then yes, that's right.

Sorry for my lack of knowledge; I have only just started getting into sid.
It looks really good and I hope to be using it much more in the future.
Thanks for your prompt and helpful support.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655