Re: [ECOS] Flash support additional RAM usage.

[Nick Garnett <nickg at ecoscentric dot com>]

"David Ho" <davidkwho@gmail.com> writes:

> Hi,
> 
> I have noticed that when flash support is added to RedBoot the overall
> usage of RAM is more than doubled (+ 77KB roughly).  Now I understand
> that when we program/erase flash, flash is not accessible so code has
> to be run from RAM.  But 77KB is a lot more than the flash routines
> themselves.
> 
> (Note that, our system has 256KB internal RAM, 1MB external RAM).
> 
> Now because in our specific case, we are attempting to maximize the
> use of internal RAM for application code, loaded using an ELF file
> programmed in flash.  We have a number of options, but a number of
> which requires knowing quite intimately what RedBoot is doing with the
> 77KB of RAM.  Here are the options:
> 
> 1) Overwrite RedBoot RAM upper memory region with application code
> during the "load" command.
> 2) Make RedBoot use as little RAM as is necessary.
> 3) Move RedBoot code to external RAM and leave region reserved.
> 
> Option 1. requires knowing whether RedBoot runs code in RAM when it is
> not managing flash, i.e. during normal application boot-up sequence.
> Option 2. requires knowing whether there is a simple way to reduce
> RedBoot memory usage.
> Option 3 means that those 77KB of external RAM is locked during
> application loading, and thus only become assessible as a heap perhaps
> when control is given to application.
> 
> I would very much appreciate if an expert can shed some lights on this issue.

Most of that 77k is a 64k block buffer for the FIS and fconfig
data. The RedBoot flash code rewrites the whole block each time it is
changed. It generally only uses this RAM during flash update
operations.

You can eliminate it by disabling the FIS and fconfig support in
RedBoot. Alternatively, just change the .ldi file to put this block,
or all of RedBoot's RAM usage, into external RAM. 

It is perfectly sensible for an application to overwrite this buffer
and the rest of RedBoot's workspace at the top of RAM. GDB stubs and
HAL IO don't use any of this memory. However, if your application
makes calls to RedBoot to fetch config options, such as the MAC
address, then this must be done before the application overwrites the
workspace.

If you need to maximize internal RAM, then the best option is to
relocate RedBoot to external RAM. 


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


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