Re: [ECOS] Performance measurement

Re: [ECOS] Performance measurement

[Andrew Lunn]

The program is tm_basic. Its in the kernel tests directory.

    Andrew

On Wed, Jun 05, 2002 at 11:27:41AM +0200, Christer Kaivo-oja wrote:
> Hi.
> 
> Is the application that generates the performance numbers that can be seen in 
> Appendix 1 of the "Getting Stsrted with eCos" available for download?
> It would be very nice to not have to construct a testing application of my 
> own :)
> 
>   -- Christer Kaivo-oja
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Christer Kaivo-oja]

On Wednesday 05 June 2002 13.45, you wrote:
> On Wed, Jun 05, 2002 at 12:38:16PM +0200, Christer Kaivo-oja wrote:
> > On Wednesday 05 June 2002 11.27, you wrote:
> > > The program is tm_basic. Its in the kernel tests directory.
> > >
> > >     Andrew
> >
> > Thank you very much.... Now the world is back to normal.. I'm having
> > problems again... ;)
> >
> > I am able to run some of the kernel tests just fine (loading them using
> > the gdb stub I have up and running), but when I try to run the tm_basic
> > test, I get a SIGTRAP even before the startup breakpoint. The cygstart of
> > tm_basic doesn't get called at all for some reason.. Any ideas on what it
> > might be?
>
> Decode the sigtrap information. It should give you an program counter
> at least. You can then work out what function it was in at the
> time. That should give you some clues.
>
> tm_basic is probably not the best program for debugging a HAL. Its
> probably the most compless.  I would get all the other test programs
> working first. Run the hal/common onces first, then the kernel ones.

Well, all the other tests run just fine... Where can I find info on how to 
decode the sigtrap?

  -- Christer

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Gary Thomas]

On Wed, 2002-06-05 at 07:04, Christer Kaivo-oja wrote:
> On Wednesday 05 June 2002 13.45, you wrote:
> > On Wed, Jun 05, 2002 at 12:38:16PM +0200, Christer Kaivo-oja wrote:
> > > On Wednesday 05 June 2002 11.27, you wrote:
> > > > The program is tm_basic. Its in the kernel tests directory.
> > > >
> > > >     Andrew
> > >
> > > Thank you very much.... Now the world is back to normal.. I'm having
> > > problems again... ;)
> > >
> > > I am able to run some of the kernel tests just fine (loading them using
> > > the gdb stub I have up and running), but when I try to run the tm_basic
> > > test, I get a SIGTRAP even before the startup breakpoint. The cygstart of
> > > tm_basic doesn't get called at all for some reason.. Any ideas on what it
> > > might be?
> >
> > Decode the sigtrap information. It should give you an program counter
> > at least. You can then work out what function it was in at the
> > time. That should give you some clues.
> >
> > tm_basic is probably not the best program for debugging a HAL. Its
> > probably the most compless.  I would get all the other test programs
> > working first. Run the hal/common onces first, then the kernel ones.
> 
> Well, all the other tests run just fine... Where can I find info on how to 
> decode the sigtrap?

What's the platform?

Can you send the exact output from GDB (I'm assuming that you run it
from GDB)?


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Christer Kaivo-oja]

On Wednesday 05 June 2002 15.06, Gary Thomas wrote:
> On Wed, 2002-06-05 at 07:04, Christer Kaivo-oja wrote:
> > Well, all the other tests run just fine... Where can I find info on how
> > to decode the sigtrap?
>
> What's the platform?
>
> Can you send the exact output from GDB (I'm assuming that you run it
> from GDB)?

I'm running a SA1110 board (Trizeps by Keith & Koep) and have based my 
platform port on the assabet. I have loaded the gdb stub to 0x10000.

When I try to download the tm_basic file using insight, I get the following 
on the console:

Loading section .rom_vectors, size 0x40 lma 0x20000
Loading section .text, size 0xc7b8 lma 0x20040
Loading section .rodata, size 0xe6c lma 0x2c7f8
Loading section .data, size 0xae4 lma 0x2d664
Start address 0x20040, load size 57672
Transfer rate: 27139 bits/sec, 303 bytes/write.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0001162c in ?? ()


0x1162c is the stub breakpoint.. From objdump:

00011628 <breakpoint>:
   11628:       e7ffdefe        undefined
   1162c:       e1a0f00e        mov     pc, lr


lr contains 0x108fc which in turn is within the stub cyg_start function:

000108ec <cyg_start>:
   108ec:       e1a0c00d        mov     ip, sp
   108f0:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
   108f4:       e24cb004        sub     fp, ip, #4      ; 0x4
   108f8:       eb00034a        bl      11628 <breakpoint>
   108fc:       eafffffd        b       108f8 <cyg_start+0xc>


Also, a breakpoint at the tm_basic cygstart doesn't change anything.. That 
particular piece of code isn't run at all...

  -- Christer

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Gary Thomas]

On Wed, 2002-06-05 at 07:53, Christer Kaivo-oja wrote:
> On Wednesday 05 June 2002 15.06, Gary Thomas wrote:
> > On Wed, 2002-06-05 at 07:04, Christer Kaivo-oja wrote:
> > > Well, all the other tests run just fine... Where can I find info on how
> > > to decode the sigtrap?
> >
> > What's the platform?
> >
> > Can you send the exact output from GDB (I'm assuming that you run it
> > from GDB)?
> 
> I'm running a SA1110 board (Trizeps by Keith & Koep) and have based my 
> platform port on the assabet. I have loaded the gdb stub to 0x10000.
> 

How do you get the GDB stubs into memory at 0x10000?

> When I try to download the tm_basic file using insight, I get the following 
> on the console:
> 
> Loading section .rom_vectors, size 0x40 lma 0x20000
> Loading section .text, size 0xc7b8 lma 0x20040
> Loading section .rodata, size 0xe6c lma 0x2c7f8
> Loading section .data, size 0xae4 lma 0x2d664
> Start address 0x20040, load size 57672
> Transfer rate: 27139 bits/sec, 303 bytes/write.
> 

Did you give some other command here?

> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0001162c in ?? ()
> 

My guess is that this address (0x20000) overlaps with your GDB stubs.

* just a query: Have you considered running RedBoot on your board?


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Christer Kaivo-oja]

On Wednesday 05 June 2002 15.58, Gary Thomas wrote:
> On Wed, 2002-06-05 at 07:53, Christer Kaivo-oja wrote:
> > On Wednesday 05 June 2002 15.06, Gary Thomas wrote:
> > > On Wed, 2002-06-05 at 07:04, Christer Kaivo-oja wrote:
> > > > Well, all the other tests run just fine... Where can I find info on
> > > > how to decode the sigtrap?
> > >
> > > What's the platform?
> > >
> > > Can you send the exact output from GDB (I'm assuming that you run it
> > > from GDB)?
> >
> > I'm running a SA1110 board (Trizeps by Keith & Koep) and have based my
> > platform port on the assabet. I have loaded the gdb stub to 0x10000.
>
> How do you get the GDB stubs into memory at 0x10000?

I compile the stub by doing:
ecosconfig new trizeps stubs
ecosconfig tree
make

the 0x10000 is hardcoded into the memory map...

Then I run this application from Keith & Koep to append a header to the 
gdb_module.img, and the new file is sent over ethernet (bootp) onto the eval 
board using the K&K bootstrap loader. Nothing too complicated there...

I can build the libtarget.a from "ecosconfig new trizeps" just fine, and all 
the examples in [...]/examples/ run just fine through gdb (or, well.. 
Insight)..


> > When I try to download the tm_basic file using insight, I get the
> > following on the console:
> >
> > Loading section .rom_vectors, size 0x40 lma 0x20000
> > Loading section .text, size 0xc7b8 lma 0x20040
> > Loading section .rodata, size 0xe6c lma 0x2c7f8
> > Loading section .data, size 0xae4 lma 0x2d664
> > Start address 0x20040, load size 57672
> > Transfer rate: 27139 bits/sec, 303 bytes/write.
>
> Did you give some other command here?

No. This is the what I get when I open the tm_basic file using the menus in 
insight and press the "Run" button.. Note that all the other kernel tests 
work just fine with this method...

> > 0x0001162c in ?? ()
>
> My guess is that this address (0x20000) overlaps with your GDB stubs.

It shouldn't.. Here's the objdump -h of the stub:
# arm-elf-objdump -h gdb_module.img

gdb_module.img:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_aranges 00000c60  00000000  00000000  000104bc  2**0
                  CONTENTS, READONLY, DEBUGGING
  1 .debug_pubnames 00001686  00000000  00000000  0001111c  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .debug_info   000186a2  00000000  00000000  000127a2  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_abbrev 00002515  00000000  00000000  0002ae44  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_line   0000ad46  00000000  00000000  0002d359  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_frame  00002324  00000000  00000000  000380a0  2**2
                  CONTENTS, READONLY, DEBUGGING
  6 .rom_vectors  00000040  00010000  00010000  00008000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  7 .text         00007d30  00010040  00010040  00008040  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .fini         00000000  00017d70  00017d70  0003a3c4  2**0
                  CONTENTS
  9 .rodata       0000026c  00017d70  00017d70  0000fd70  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .rodata1      00000000  00017fdc  00017fdc  0003a3c4  2**0
                  CONTENTS
 11 .fixup        00000000  00017fdc  00017fdc  0003a3c4  2**0
                  CONTENTS
 12 .gcc_except_table 00000000  00017fdc  00017fdc  0003a3c4  2**0
                  CONTENTS
 13 .fixed_vectors 00000160  00000020  00000020  0003a3e0  2**5
                  CONTENTS, READONLY
 14 .data         000004bc  00080000  00017fdc  00010000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 15 .bss          00010a98  000804bc  000804bc  000104bc  2**4
                  ALLOC

There should be plenty of space at 0x20000...


> * just a query: Have you considered running RedBoot on your board?

Well.. I tried it very briefly, and it seemed to work just fine.. But it's 
very close in functionality to the K&K bootstrap loader, so I really didn't 
see the point... Also, I don't have the ethernet connector functioning at 
this point, so I'd still be locked to the rs232 port..

  -- Christer

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Gary Thomas]

On Wed, 2002-06-05 at 08:17, Christer Kaivo-oja wrote:
> On Wednesday 05 June 2002 15.58, Gary Thomas wrote:
> > On Wed, 2002-06-05 at 07:53, Christer Kaivo-oja wrote:
> > > On Wednesday 05 June 2002 15.06, Gary Thomas wrote:
> > > > On Wed, 2002-06-05 at 07:04, Christer Kaivo-oja wrote:
> > > > > Well, all the other tests run just fine... Where can I find info on
> > > > > how to decode the sigtrap?
> > > >
> > > > What's the platform?
> > > >
> > > > Can you send the exact output from GDB (I'm assuming that you run it
> > > > from GDB)?
> > >
> > > I'm running a SA1110 board (Trizeps by Keith & Koep) and have based my
> > > platform port on the assabet. I have loaded the gdb stub to 0x10000.
> >
> > How do you get the GDB stubs into memory at 0x10000?
> 
> I compile the stub by doing:
> ecosconfig new trizeps stubs
> ecosconfig tree
> make
> 
> the 0x10000 is hardcoded into the memory map...
> 
> Then I run this application from Keith & Koep to append a header to the 
> gdb_module.img, and the new file is sent over ethernet (bootp) onto the eval 
> board using the K&K bootstrap loader. Nothing too complicated there...
> 
> I can build the libtarget.a from "ecosconfig new trizeps" just fine, and all 
> the examples in [...]/examples/ run just fine through gdb (or, well.. 
> Insight)..
> 
> 
> > > When I try to download the tm_basic file using insight, I get the
> > > following on the console:
> > >
> > > Loading section .rom_vectors, size 0x40 lma 0x20000
> > > Loading section .text, size 0xc7b8 lma 0x20040
> > > Loading section .rodata, size 0xe6c lma 0x2c7f8
> > > Loading section .data, size 0xae4 lma 0x2d664
> > > Start address 0x20040, load size 57672
> > > Transfer rate: 27139 bits/sec, 303 bytes/write.
> >
> > Did you give some other command here?
> 
> No. This is the what I get when I open the tm_basic file using the menus in 
> insight and press the "Run" button.. Note that all the other kernel tests 
> work just fine with this method...
> 

The 'Run' button issues a number of GDB commands.  In particular, it
will have told the program to start up and it is failing before it even
gets to the entry point of 'tm_basic'

> > > 0x0001162c in ?? ()
> >
> > My guess is that this address (0x20000) overlaps with your GDB stubs.
> 
> It shouldn't.. Here's the objdump -h of the stub:
> # arm-elf-objdump -h gdb_module.img
> 
> gdb_module.img:     file format elf32-littlearm
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .debug_aranges 00000c60  00000000  00000000  000104bc  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   1 .debug_pubnames 00001686  00000000  00000000  0001111c  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   2 .debug_info   000186a2  00000000  00000000  000127a2  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   3 .debug_abbrev 00002515  00000000  00000000  0002ae44  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   4 .debug_line   0000ad46  00000000  00000000  0002d359  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   5 .debug_frame  00002324  00000000  00000000  000380a0  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   6 .rom_vectors  00000040  00010000  00010000  00008000  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   7 .text         00007d30  00010040  00010040  00008040  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   8 .fini         00000000  00017d70  00017d70  0003a3c4  2**0
>                   CONTENTS
>   9 .rodata       0000026c  00017d70  00017d70  0000fd70  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  10 .rodata1      00000000  00017fdc  00017fdc  0003a3c4  2**0
>                   CONTENTS
>  11 .fixup        00000000  00017fdc  00017fdc  0003a3c4  2**0
>                   CONTENTS
>  12 .gcc_except_table 00000000  00017fdc  00017fdc  0003a3c4  2**0
>                   CONTENTS
>  13 .fixed_vectors 00000160  00000020  00000020  0003a3e0  2**5
>                   CONTENTS, READONLY
>  14 .data         000004bc  00080000  00017fdc  00010000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>  15 .bss          00010a98  000804bc  000804bc  000104bc  2**4
>                   ALLOC
> 
> There should be plenty of space at 0x20000...

Ah, but the stubs are also using memory at 0x80000!  So, the programs
you are downloading have to live within the space 0x20000..0x7FFFF.

The 'tm_basic' program has some very large arrays (which don't show up
when loading).  These will most certainly overlap with 0x80000 and
beyond.  When you run the program, some of the very early startup code
clears all of the "bss" memory, which I'm sure is what is killing the
GDB stubs.

One way to move ahead quickly would be to adjust tm_basic to not use
so much memory.  A quick glance at the source code will tell you how.

> 
> 
> > * just a query: Have you considered running RedBoot on your board?
> 
> Well.. I tried it very briefly, and it seemed to work just fine.. But it's 
> very close in functionality to the K&K bootstrap loader, so I really didn't 
> see the point... Also, I don't have the ethernet connector functioning at 
> this point, so I'd still be locked to the rs232 port..

Once you get those things straightened out, you might reconsider.  After
all, you'd then have complete control over everything that happens on 
the platform - in source :-)



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Christer Kaivo-oja]

On Wednesday 05 June 2002 16.17, Christer Kaivo-oja wrote:
> On Wednesday 05 June 2002 15.58, Gary Thomas wrote:
> > On Wed, 2002-06-05 at 07:53, Christer Kaivo-oja wrote:
> > > On Wednesday 05 June 2002 15.06, Gary Thomas wrote:
> > > > On Wed, 2002-06-05 at 07:04, Christer Kaivo-oja wrote:

> > My guess is that this address (0x20000) overlaps with your GDB stubs.
>
> It shouldn't.. Here's the objdump -h of the stub:
> # arm-elf-objdump -h gdb_module.img
>
> gdb_module.img:     file format elf32-littlearm
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  14 .data         000004bc  00080000  00017fdc  00010000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>  15 .bss          00010a98  000804bc  000804bc  000104bc  2**4
>                   ALLOC
>
> There should be plenty of space at 0x20000...
>

Hmm.. Or maybe not as plenty as I thought... Looking at the tm_basic's 
objdump I see the following:

 15 .bss          00b26eb4  0002e148  0002e148  00016148  2**4
                  ALLOC

This bss field is most definately overlapping the stub bss at 0x80000... 
Guess I should move the stubs bss field somewhere safe... :)

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Andrew Lunn]

> Well, all the other tests run just fine... Where can I find info on how to 
> decode the sigtrap?

I forget the format. Maybe gdb can do that already? Does it give an
address? If so, use the disassemble command.

(gdb) disassemble 0x107a580
Dump of assembler code for function printf:
0x107a578 <printf>:     push   %ebp
0x107a579 <printf+1>:   mov    %esp,%ebp
0x107a57b <printf+3>:   sub    $0x8,%esp
0x107a57e <printf+6>:   lea    0xc(%ebp),%eax
0x107a581 <printf+9>:   push   %eax
0x107a582 <printf+10>:  pushl  0x8(%ebp)
0x107a585 <printf+13>:  push   $0x7fffffff
0x107a58a <printf+18>:  pushl  0x1159ac0
0x107a590 <printf+24>:  call   0x107a5a0 <vfnprintf>
0x107a595 <printf+29>:  leave  
0x107a596 <printf+30>:  ret    
End of assembler dump.

Here you can see that its figured out that the address 0x107a580 is in
the middle of printf...

    Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Performance measurement

[Christer Kaivo-oja]

Ooops.. forgot to CC here.. :)


On Wednesday 05 June 2002 11.27, you wrote:
> The program is tm_basic. Its in the kernel tests directory.
>
>     Andrew

Thank you very much.... Now the world is back to normal.. I'm having problems
again... ;)

I am able to run some of the kernel tests just fine (loading them using the
gdb stub I have up and running), but when I try to run the tm_basic test, I
get a SIGTRAP even before the startup breakpoint. The cygstart of tm_basic
doesn't get called at all for some reason.. Any ideas on what it might be?

And oh, nothing really happens if I try to download the tm_basic file in
place of the stub either..

  -- Christer Kaivo-oja

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] Performance measurement

[Christer Kaivo-oja]

Hi.

Is the application that generates the performance numbers that can be seen in 
Appendix 1 of the "Getting Stsrted with eCos" available for download?
It would be very nice to not have to construct a testing application of my 
own :)

  -- Christer Kaivo-oja

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss