[ECOS] ecos mem footprint with HTTPD support

[ECOS] ecos mem footprint with HTTPD support

[Mandeep Sandhu]

Hi all,

Just as I got a rough estimate of how much mem (worst case) my hello world
app along with the rest of the ecos libs take, is there any sample prog which I
can use to ascertain the runtime size of my app which uses the HTTPD pkg?

Should I write some sample prog which makes use of the HTTP pkg to determine
the size or are there example programs available which make use of this pkg?

Thanks,
-mandeep

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

[ECOS] Re: ecos mem footprint with HTTPD support

[John Dallaway]

Hi Mandeep

Mandeep Sandhu wrote:

> Just as I got a rough estimate of how much mem (worst case) my hello world
> app along with the rest of the ecos libs take, is there any sample prog which I
> can use to ascertain the runtime size of my app which uses the HTTPD pkg?

Note that the HTTPD package is intended for use with the eCos FreeBSD
TCP/IP stack, not lwIP.

The lwIP TCP/IP stack provides its own HTTP server test. Simply
configure eCos for lwIP networking and then build eCos and the eCos
tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the
resulting "httpd" test executable file.

John Dallaway

-- 
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] Re: ecos mem footprint with HTTPD support

[Sergei Gavrikov]

John Dallaway wrote:
> Hi Mandeep
> 
> Mandeep Sandhu wrote:
> 
> > Just as I got a rough estimate of how much mem (worst case) my hello world
> > app along with the rest of the ecos libs take, is there any sample prog which I
> > can use to ascertain the runtime size of my app which uses the HTTPD pkg?
> 
> Note that the HTTPD package is intended for use with the eCos FreeBSD
> TCP/IP stack, not lwIP.
> 
> The lwIP TCP/IP stack provides its own HTTP server test. Simply
> configure eCos for lwIP networking and then build eCos and the eCos
> tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the
> resulting "httpd" test executable file.

To know its sizes and to peace a linker I use a trick (workaround for
"section .bss is not within region ram" error).

Let's call it "How much is The Fish". It is

sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld

it just multiply target's ram size on 16 :-)

I run this 1-line sed script before to build the tests.

The below is just an example (I have no target)

ecosconfig new sam7ex256 lwip_eth
ecosconfig tree
make
sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld
make -C net/lwip_tcpip/current/ tests TESTS=tests/httpd

   text	   data	    bss	    dec	    hex	filename
  71240	   5428	 102808	 179476	  2bd14	httpd

Ups... But, AFAIK, lwip's pbufs sucks RAM. Default number of pbufs is
60, its default size is 1K. 60x1K... Well, let's reduce amount of the
buffers, i.e. import the below

cdl_option CYGNUM_LWIP_PBUF_POOL_SIZE {
    user_value 6
};

and rebuild the test

   text	   data	    bss	    dec	    hex	filename
  71240	   5428	  46648	 123316	  1e1b4	httpd

It is something more interesting, but, I could break down the lwip
networking. I do not know. To reduce text segment you can disable udp,
raw ethernet support, etc., etc. (it's eCos).

Hey, do not forget to revert ld script! It's easy if you use bash
history

sed -i '/ram.*LENGTH/s,0$,,' isntall/lib/target.ld

And now, without jokes. Look at Adam Dunkel's uIP TCP/IP stack
http://www.sics.se/~adam/uip/

and his invention, - Protothreads (Stackless Threads in C)
http://www.sics.se/~adam/pt/

I have a dream to try eCos together with Adam's Protothreads. If it will
allright, it will be possible to get unbeatable sizes for small memory
footprint targets.


Sergei

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

[ECOS] Re: ecos mem footprint with HTTPD support

[Mandeep Sandhu]

> The lwIP TCP/IP stack provides its own HTTP server test. Simply
> configure eCos for lwIP networking and then build eCos and the eCos
> tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the
> resulting "httpd" test executable file.

Thanks for the tip John.

But the test compilation is failing with the following error:

make[1]: Leaving directory
`/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_build/infra/v3_0'
/home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld:
address 0x219ae8 of
/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/diag_sprintf2
section .bss is not within region ram
make: Leaving directory `/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_build'
/home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld:
address 0x219ae8 of
/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/diag_sprintf2
section .bss is not within region ram

collect2: ld returned 1 exit status
make[1]: *** [/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/diag_sprintf2]
Error 1
make[1]: *** Waiting for unfinished jobs....
/home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld:
address 0x21a4d8 of
/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/cxxsupp
section .bss is not within region ram
/home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld:
address 0x21a4d8 of
/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/cxxsupp
section .bss is not within region ram
collect2: ld returned 1 exit status
make[1]: *** [/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/cxxsupp]
Error 1
make: *** [tests] Error 2

I have created a fresh config, choosing the at91sam7ex with iwIP
template. The build passes, but the tests
compilation is failing.

The above errors are a little beyond me...but does it mean we've run
out of RAM? Can I increase the amount
of RAM in some config...for the sam7ex template?

Thanks,
-mandeep

>
> John Dallaway
>

-- 
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] Re: ecos mem footprint with HTTPD support

[Mandeep Sandhu]

Wow Sergei! some telepathy you have...how'd you know I was about
to post the error .bss error! :)

seems like a std error? now back to reading your reply :) .....

On Wed, Jul 15, 2009 at 6:48 PM, Sergei
Gavrikov<sergei.gavrikov@gmail.com> wrote:
> John Dallaway wrote:
>> Hi Mandeep
>>
>> Mandeep Sandhu wrote:
>>
>> > Just as I got a rough estimate of how much mem (worst case) my hello world
>> > app along with the rest of the ecos libs take, is there any sample prog which I
>> > can use to ascertain the runtime size of my app which uses the HTTPD pkg?
>>
>> Note that the HTTPD package is intended for use with the eCos FreeBSD
>> TCP/IP stack, not lwIP.
>>
>> The lwIP TCP/IP stack provides its own HTTP server test. Simply
>> configure eCos for lwIP networking and then build eCos and the eCos
>> tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the
>> resulting "httpd" test executable file.
>
> To know its sizes and to peace a linker I use a trick (workaround for
> "section .bss is not within region ram" error).
>
> Let's call it "How much is The Fish". It is
>
> sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld
>
> it just multiply target's ram size on 16 :-)
>
> I run this 1-line sed script before to build the tests.
>
> The below is just an example (I have no target)
>
> ecosconfig new sam7ex256 lwip_eth
> ecosconfig tree
> make
> sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld
> make -C net/lwip_tcpip/current/ tests TESTS=tests/httpd
>
>   text    data     bss     dec     hex filename
>  71240    5428  102808  179476   2bd14 httpd
>
> Ups... But, AFAIK, lwip's pbufs sucks RAM. Default number of pbufs is
> 60, its default size is 1K. 60x1K... Well, let's reduce amount of the
> buffers, i.e. import the below
>
> cdl_option CYGNUM_LWIP_PBUF_POOL_SIZE {
>    user_value 6
> };
>
> and rebuild the test
>
>   text    data     bss     dec     hex filename
>  71240    5428   46648  123316   1e1b4 httpd
>
> It is something more interesting, but, I could break down the lwip
> networking. I do not know. To reduce text segment you can disable udp,
> raw ethernet support, etc., etc. (it's eCos).
>
> Hey, do not forget to revert ld script! It's easy if you use bash
> history
>
> sed -i '/ram.*LENGTH/s,0$,,' isntall/lib/target.ld
>
> And now, without jokes. Look at Adam Dunkel's uIP TCP/IP stack
> http://www.sics.se/~adam/uip/
>
> and his invention, - Protothreads (Stackless Threads in C)
> http://www.sics.se/~adam/pt/
>
> I have a dream to try eCos together with Adam's Protothreads. If it will
> allright, it will be possible to get unbeatable sizes for small memory
> footprint targets.
>
>
> Sergei
>

--
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] Re: ecos mem footprint with HTTPD support

[Sergei Gavrikov]

Mandeep Sandhu wrote:
> 
> seems like a std error? now back to reading your reply :) .....

That error is not surprise for small memory footprint targets. I hope
you get it. That trick did not fit an external RAM on your board, It did
deceive linker and then you can use `size' utility.


Sergei

-- 
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] Re: ecos mem footprint with HTTPD support

[Mandeep Sandhu]

On Wed, Jul 15, 2009 at 7:27 PM, Sergei
Gavrikov<sergei.gavrikov@gmail.com> wrote:
> Mandeep Sandhu wrote:
>>
>> seems like a std error? now back to reading your reply :) .....
>
> That error is not surprise for small memory footprint targets. I hope
> you get it. That trick did not fit an external RAM on your board, It did
> deceive linker and then you can use `size' utility.

Yes, I suspected that much. But tell me, where does the linker get the RAM
size constraint for the atmel board...i.e the sam7ex256? It must be configured
somewhere...as part of a template...no?

Couldn't we have "added" RAM there?

BTW, your trick worked...I pretty much get the same numbers as you
had shown...

Before reducing PBUF pool size:

arm-eabi-size test_install/tests/net/lwip_tcpip/v3_0/tests/httpd
   text	   data	    bss	    dec	    hex	filename
  71512	   5440	 102796	 179748	
2be24	test_install/tests/net/lwip_tcpip/v3_0/tests/httpd

After reducing it to 6:

arm-eabi-size test_install/tests/net/lwip_tcpip/v3_0/tests/httpd
   text	   data	    bss	    dec	    hex	filename
  71512	   5440	  46636	 123588	
1e2c4	test_install/tests/net/lwip_tcpip/v3_0/tests/http

So this figure is not too different from the FreeRTOS numbers for
similar app :)...

~/freeRTOS/FreeRTOS/Demo/lwIP_Demo_Rowley_ARM7$
~/gnuarm/gnuarm-3.4.3/bin/arm-elf-size rtosdemo.elf
   text	   data	    bss	    dec	    hex	filename
 119096	   2016	  62736	 183848	  2ce28	rtosdemo.elf

Do you think 256K RAM will be enough to run a similarly configured
system (with additional
USB device and SPI driver support) on ARM7 based embedded SoC?

-mandeep

>
>
> Sergei
>

-- 
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] Re: ecos mem footprint with HTTPD support

[Sergei Gavrikov]

On Wed, Jul 15, 2009 at 07:35:01PM +0530, Mandeep Sandhu wrote:
> On Wed, Jul 15, 2009 at 7:27 PM, Sergei
> Gavrikov<sergei.gavrikov@gmail.com> wrote:
> > Mandeep Sandhu wrote:
> >>
> >> seems like a std error? now back to reading your reply :) .....
> >
> > That error is not surprise for small memory footprint targets. I hope
> > you get it. That trick did not fit an external RAM on your board, It did
> > deceive linker and then you can use `size' utility.
> 
> Yes, I suspected that much. But tell me, where does the linker get the RAM
> size constraint for the atmel board...i.e the sam7ex256? It must be configured
> somewhere...as part of a template...no?
> 
> Couldn't we have "added" RAM there?
> 

That is defined in plf mlt files. I guess here for your target
hal/arm/at91/at91sam7s/current/include/pkgconf/mlt*

[snip]

> Do you think 256K RAM will be enough to run a similarly configured
> system (with additional USB device and SPI driver support) on ARM7
> based embedded SoC?

IMO, it will be possible, if you will use lwIP TCP/IP stack.

Sergei

-- 
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] Re: ecos mem footprint with HTTPD support

[Mandeep Sandhu]

>> Couldn't we have "added" RAM there?
>>
>
> That is defined in plf mlt files. I guess here for your target
> hal/arm/at91/at91sam7s/current/include/pkgconf/mlt*
>
Ok will check that. Thanks.

> [snip]
>
>> Do you think 256K RAM will be enough to run a similarly configured
>> system (with additional USB device and SPI driver support) on ARM7
>> based embedded SoC?
>
> IMO, it will be possible, if you will use lwIP TCP/IP stack.

I think I was wrongly calculating my RAM usage for the sample HTTPD
app (using lwIP).

When looking for the runtime RAM usage of my app+kernel...I should
add the bss+data+rwdata (if any) sections...right?

.text and .rodata will reside in the flash only. Am I correct in this
assumption?
Do all embedded systems work this way...i.e the code/text and rodata sections
reside in the flash and rest is loaded into the RAM? Who maps these addresses?
The linker script?

Because with this calc, my RAM requirement gets reduced drastically.

Also, any tips on how much space I should keep for expansion of the RW
area's?

Say my bss+data+rwdata comes to around 55KB...is it safe to go with a
system with 64KB on-chip RAM? Is 9KB margin safe enough?

thanks as always,
-mandeep

>
> Sergei
>

-- 
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] Re: ecos mem footprint with HTTPD support

[Sergei Gavrikov]

On Thu, Jul 16, 2009 at 02:24:33PM +0530, Mandeep Sandhu wrote:
> I think I was wrongly calculating my RAM usage for the sample HTTPD
> app (using lwIP).

man size. By default format is short (Berkeley format). Try -Ax for size
run and you will see all locations. For reading: man readelf, man objdump.
MLT stands from Memory LayouT.

Sergei


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

[ECOS] Re: ecos mem footprint with HTTPD support

[John Dallaway]

Hi Mandeep

Mandeep Sandhu wrote:

> I think I was wrongly calculating my RAM usage for the sample HTTPD
> app (using lwIP).
> 
> When looking for the runtime RAM usage of my app+kernel...I should
> add the bss+data+rwdata (if any) sections...right?

Yes, for eCos applications built for ROM startup. There will also be a
small area of RAM reserved for various vectors.

> .text and .rodata will reside in the flash only. Am I correct in this
> assumption?

Yes, for eCos applications built for ROM startup. The Flash will also
hold the original copy of the pre-initialised static data which is
copied to RAM at startup (.data section).

Note also that a few small fragments of _code_ are also relocated to RAM
(eg low-level Flash I/O code).

> Do all embedded systems work this way...i.e the code/text and rodata sections
> reside in the flash and rest is loaded into the RAM?

They should do when configured for ROM startup.

> Who maps these addresses?
> The linker script?

Correct.

> Also, any tips on how much space I should keep for expansion of the RW
> area's?

There is no expansion of the linker-defined sections. Thread-local
variables are stored on the thread stacks. These stacks are typically
allocated as static arrays. Some packages use their own
statically-allocated memory pools. You must decide how large these
stacks and memory pools need to be where necessary.

If you must use malloc() and related functions, the eCos dynamic memory
allocation package will allocate memory from the heap. The heap
typically occupies all remaining RAM above the application code and
data. Clearly, allocations from the heap are additional to anything
known to the linker and reported by the "size" tool.

> Say my bss+data+rwdata comes to around 55KB...is it safe to go with a
> system with 64KB on-chip RAM? Is 9KB margin safe enough?

You need no margin at all if you avoid dynamic memory allocation.

I hope this helps...

John Dallaway

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

[ECOS] Re: ecos mem footprint with HTTPD support

[Mandeep Sandhu]

>
> There is no expansion of the linker-defined sections. Thread-local
> variables are stored on the thread stacks. These stacks are typically
> allocated as static arrays. Some packages use their own
> statically-allocated memory pools. You must decide how large these
> stacks and memory pools need to be where necessary.
>
> If you must use malloc() and related functions, the eCos dynamic memory
> allocation package will allocate memory from the heap. The heap
> typically occupies all remaining RAM above the application code and
> data. Clearly, allocations from the heap are additional to anything
> known to the linker and reported by the "size" tool.
>
>> Say my bss+data+rwdata comes to around 55KB...is it safe to go with a
>> system with 64KB on-chip RAM? Is 9KB margin safe enough?
>
> You need no margin at all if you avoid dynamic memory allocation.
>
> I hope this helps...

Thanks for clearing this. This does help a lot!

Regards,
-mandeep

>
> John Dallaway
>

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