Blackfin port footprint bss > 500K ?

[Joel Sherrill]

Devin Butterfield wrote:
> Hi folks,
>
> Using the cvs head RTEMS, binutils 2.18, gcc-4.3.1, I built RTEMS 
> using the following options:
>
> ../rtems/configure --target=bfin-rtems --disable-posix 
> --disable-networking --enable-rtemsbsp=eZKit533 --disable-itron 
> --prefix=$PWD --enable-tests
>
> The footprint I get for minimum.exe is surprisingly large (when 
> compared to say the m68k port):
>
>    text    data     bss     dec     hex filename
>   53152    2344  595832  651328   9f040 minimum.exe
>
>
> I poked around in the code and found that the linker cmds are 
> reserving 512K for the RTEMS workspace in .bss:
>
>         _WorkspaceBase = .;
>         . += 512K;      /* reserve some memory for workspace */
>
> I'm new to RTEMS, and so I don't know what the workspace is used for, 
> but I don't see other targets (e.g., m68k) reserving this much memory.
>
> Is a 512K workspace really required for the bfin port? Can we make it 
> smaller?
No.  Yes. :-D 

The workspace required is a function of the number of RTEMS objects you
use plus stacks and message buffers.  I think most of the sptests can run
with <= 64K workspace.  The minimum size is currently in the 1.5K range
I think.  It depends heavily on the configured number of tasks, configured
minimum stack size and real task stacks sizes and the number of configured
priorities.  ticker.exe has 5 tasks (3 w/8K stack, 2 w/4K stacks ==> 40K)
plus termios, 256 priority levels (~3K), etc and only needs 50120
bytes of workspace. 

Seriously this isn't the right way to do things.  The proper way is to 
either
have the linkcmds know the starting and ending address of RAM (hence
the size of RAM) or to probe it during startup.

Recently, I added support for boot_card() to do more of the dirty work of
memory allocation.  The BSP just provides a hook and defines a couple
of constants.  The hook's purpose is to let bootcard discover the
amount of free RAM available for the C program heap and Workspace
between the end of the .bss (and maybe startup stack) and the end
of RAM.  Then bootcard.c gives RTEMS what it needs and gives the
remainder to the C program heap.

  void bsp_get_work_area(
    void **work_area_start,
    size_t *work_area_size,
    void **heap_start,
    size_t *heap_size
  );

See the sparc/erc32 BSP for a fairly simple example.  configure.ac
has RTEMS_BSP_BOOTCARD_HANDLES_RAM_ALLOCATION near
the bottom which enables this support in bootcard.c.  The sparc
shared/bspstart.c includes the method implementation for all
sparc BSPs.

I would love to see the bfin BSPs converted to this new way
which actually is easier to read and less BSP specific code.

>
> Thanks!
> --
> Regards, Devin


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985