Re: [ECOS] Performance measurement

[Gary Thomas <gary at chez-thomas dot org>]

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