[ECOS] Default CME555 too big

[ECOS] Default CME555 too big

[Eric Castle]

Hi Bob,

We're at it again, this time trying to run some sample eCos programs on our
Axiom board (now running RedBoot in internal ROM).  We also got the flash
drivers working for RedBoot, which took some doing as our board did not come
with precise model of flash (but on the plus, we should have access to 1 MB,
instead of just 512 KB).

However, when we built the eCos library (using the CME555 template and the
default package) and made the example programs, they came in around 1 MB,
much too big to run from external RAM.  Is there a different package we
should be using here to build the library?

We attempted to build our own version, only including packages we thought
important for running the "hello world" program.  Below is a list of all the
packages in the "default" setup.  We started with the "minimal" build
(marked with *'s), and then added everything we thought we'd need (%):

*Axiom's CME555 evaluation board
%C library
*Common error code support
Dynamic memory allocation
*FLASH memory support for Axiom's CME555
*I/O sub-system
*ISO C and POSIX infrastructure
ISO C library date/time functions
ISO C library general utility functions
ISO C library internationalization
ISO C library non-local jumps
ISO C library signals
%ISO C library standard input/output functions
%ISO C library string functions
ISO environment startup/termination
*Infrastructure
Math library
*PowerPC 5xx variant HAL
*PowerPC common HAL
%Serial device drivers
*Support for AMD AM29xxxxx flash memory
Wallclock device framework
*Wallclock driver for mpc5xx RTC module
*cme555 PowerPC serial device drivers
*eCos common HAL
eCos kernel

We got an eCos library and linked it against the example programs, getting
something now more like 300 KB.

But downloading that to RAM via gdb hasn't produced anything.  Generally we
do the following:

% powerpc-eabi-gdb hello

(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
(gdb) continue

And then it just hangs.  Adding breakpoints doesn't seem to make any
difference, as it generally ignores them (once it stopped at a breakpoint,
but that was completely unrepeatable).

So, I was wondering if you:
1) Knew how we should be building our eCos library so the programs are small
enough to fit into external RAM.
2) Saw a mistake in how we're using gdb.

Thanks,

-Eric Castle

C&DH Subsystem - FEGI Team
University of Michigan



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

Re: [ECOS] Default CME555 too big

[Andrew Lunn]

> However, when we built the eCos library (using the CME555 template and the
> default package) and made the example programs, they came in around 1 MB,
> much too big to run from external RAM.  Is there a different package we
> should be using here to build the library?

I presume the 1MB is the size of the elf file and not the binary. Run 

powerpc-eabi-size(1) on the elf to find out the size of the binary.

> But downloading that to RAM via gdb hasn't produced anything.  Generally we
> do the following:
> 
> % powerpc-eabi-gdb hello
> 
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> (gdb) continue

Err, what about the load command?

        Andrew

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

RE: [ECOS] Default CME555 too big

[Eric Castle]

RE: Too big
Interesting.  I ran powerpc-eabi-size on my hello.elf program that was about
1 MB, and it printed out the following:

% powerpc-eabi-size hello
	text		data	bss	dec	hex	filename
	52040		0	16420	68460	10b6c	hello

Which does seem to indicate a much smaller executable.  I compiled eCos
without the "-g" flag, and a huge portion of that 1 MB went away.  So I
guess I shouldn't be having trouble fiting stuff into external RAM.

RE: gdb
Ack, sorry, yes, I run the load command as well:

(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x0000bbe0 in ?? ()
(gdb) load
Loading section .text, size 0xa29c lma 0x406000
Loading section .rodata, size 0x1568 lma 0x4102a0
Loading section .data, size 0x990 lma 0x411808
Start address 0x406000, load size 49556
Transfer rate: 30496 bits/sec, 505 bytes/write.
(gdb) where
#0  0x0000bbe0 in ?? ()
(gdb) jump _start
Continuing at 0x406018.
Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
(gdb) where
No stack.


I tried both "jump <insert likely sounding function>" and "continue", but I
never get any output after that point (asides from the one random time it
stopped at a breakpoint).

Any thoughts?

Thanks for the "powerpc-eabi-size" tip; that explains some things.

-Eric



-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Tuesday, June 08, 2004 4:19 PM
To: Eric Castle
Cc: Bob Koninckx; Ecos-Discuss
Subject: Re: [ECOS] Default CME555 too big


> However, when we built the eCos library (using the CME555 template and the
> default package) and made the example programs, they came in around 1 MB,
> much too big to run from external RAM.  Is there a different package we
> should be using here to build the library?

I presume the 1MB is the size of the elf file and not the binary. Run

powerpc-eabi-size(1) on the elf to find out the size of the binary.

> But downloading that to RAM via gdb hasn't produced anything.  Generally
we
> do the following:
>
> % powerpc-eabi-gdb hello
>
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> (gdb) continue

Err, what about the load command?

        Andrew



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

RE: [ECOS] Default CME555 too big

[Gary Thomas]

On Tue, 2004-06-08 at 15:19, Eric Castle wrote:
> RE: Too big
> Interesting.  I ran powerpc-eabi-size on my hello.elf program that was about
> 1 MB, and it printed out the following:
> 
> % powerpc-eabi-size hello
> 	text		data	bss	dec	hex	filename
> 	52040		0	16420	68460	10b6c	hello
> 
> Which does seem to indicate a much smaller executable.  I compiled eCos
> without the "-g" flag, and a huge portion of that 1 MB went away.  So I
> guess I shouldn't be having trouble fiting stuff into external RAM.
> 

This is probably the most common error that folks seem to make.  The 
executable file (ELF format) is full of debug and other structural
information.  The actual code+data which needs to be loaded in your
target hardware will be very much smaller, especially if you compile
with -g (the eCos default)

> RE: gdb
> Ack, sorry, yes, I run the load command as well:
> 
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x0000bbe0 in ?? ()
> (gdb) load
> Loading section .text, size 0xa29c lma 0x406000
> Loading section .rodata, size 0x1568 lma 0x4102a0
> Loading section .data, size 0x990 lma 0x411808
> Start address 0x406000, load size 49556
> Transfer rate: 30496 bits/sec, 505 bytes/write.
> (gdb) where
> #0  0x0000bbe0 in ?? ()
> (gdb) jump _start
> Continuing at 0x406018.
> Interrupted while waiting for the program.
> Give up (and stop debugging it)? (y or n) y
> (gdb) where
> No stack.
> 
> 
> I tried both "jump <insert likely sounding function>" and "continue", but I
> never get any output after that point (asides from the one random time it
> stopped at a breakpoint).
> 
> Any thoughts?

"continue" should work - you should not need to "jump" to a special
location.

Try single stepping and/or setting intermediate breakpoints to see
how far along your code is getting.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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