Improve ES reset area memory allocation

[jphickey]

Is your feature request related to a problem? Please describe.
Currently the PSP provides a single API CFE_PSP_GetResetArea which is sized according to a user-specified CFE_PLATFORM_ES_RESET_AREA_SIZE. with a note that says:

This area must be sized large enough to hold all of the data structures. It should be automatically sized based on the CFE_ES_ResetData_t type, but circular dependancies in the headers prevent it from being defined this way.

This is far from ideal, and in the default configuration 170KiB is allocated for this area where only 129KiB is actually used, wasting a fair bit of memory.

Furthermore, the circular dependency issue was only really a problem in the classic build. In the CMake build the "target_config" mechanism can be utilized here to make this a non-issue.

Describe the solution you'd like
The PSP generally allocates these memory spaces dynamically at start up anyway.

• In the MCP750 this is based on sysMemTop() and the addresses are calculated from this base.
• In pc-linux these are SysV shared memory segments.
• In pc-rtems these are just malloc()'ed to simplify usage in QEMU (data does not survive a reset).

CFE ES should publish the actual size required for its persistent data structures, and this actual size should be used when computing the addresses of these memory areas, rather than a compile-time fixed size which is almost certainly either too big or too small.

Additional context
This issue is related to changes occurring in the Exception and Reset Log implementation (issues #411, #76). As part of this more of the ER log (or in particular, storing of exception context) will be moved to the PSP rather than being fully managed by ES. This in turn changes the size of the CFE_ES_ResetData_t structure substantially, and exposes the weakness/issues in how this is being currently allocated.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[skliper]

@jphickey interested in fixing this for Caelum?

[jphickey]

Yes I'll check the current situation again at least. IIRC, after initially observing this issue, I found out that for the MCP750 the actual reserved area needs to be set aside when the kernel image is built, and is fixed thereafter (the current build has 4MB of the 128MB on the board set aside for this). This is what determines the sysMemTop() address that the PSP uses.

So - even if we fix the CFE+PSP builds to size this appropriately - it is still ultimately dependent on the PSP as to whether it makes any difference to the actual memory available at runtime. On MCP750 it will not, but on others it could.