"David Ho" <[EMAIL PROTECTED]> 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
