This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Performance measurement
- From: Gary Thomas <gary at chez-thomas dot org>
- To: Christer Kaivo-oja <christer dot kaivo at kvaser dot se>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 05 Jun 2002 08:24:44 -0600
- Subject: Re: [ECOS] Performance measurement
- References: <200206050926.g559Qd126562@rubicon.hasler.ascom.ch><20020605135208.737727D2@hermes.chez-thomas.org><1023285519.3245.42.camel@hermes.chez-thomas.org> <20020605141632.090AD7D2@hermes.chez-thomas.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