Rework work area initialization

[Sebastian Huber]

The work area initialization is done by the BSP through bsp_work_area_initialize(). This approach predates the system initialization through the system initialization linker set. The workspace and C program heap are unconditionally initialized. With the availability of statically initialized threads a system without workspace and C program heap is feasible. Change the work area initialization so that components are initialized on demand. To achieve this:

1. Add a Memory Handler which provides support for low level handling of memory areas which are handed over to the higher level Heap Handler.

2. Add an implementation of _Memory_Get() to each BSP (basically a restructuring of the bsp_work_area_initialize() implementations).

See optimization opportunity in #3925.

[Chris Johns]

This needs to be explained in more detail.

What happens to BSPs that are not in the tree?

[Sebastian Huber]

I am not sure what needs to be explained in more detail. This is mostly a mechanical change which just rearranges existing things a bit differently.

As usual, maintainers of BSPs which are not in the mainline RTEMS source have to pay a price and have to update their BSPs by themself. With an updated documentation, this shouldn't be an issue.

[Chris Johns]

Replying to Sebastian Huber:

I am not sure what needs to be explained in more detail. This is mostly a mechanical change which just rearranges existing things a bit differently.

I think there are somethings, for example take "components are initialized on demand", what is a "component" and what does "initialized on demand" mean?

I am OK with working through the detail but this will have to wait until I find the time. If you do not mind waiting let me know.

As usual, maintainers of BSPs which are not in the mainline RTEMS source have to pay a price and have to update their BSPs by themself. With an updated documentation, this shouldn't be an issue.

A number of users cannot submit their BSPs and we have attempted to maintain a BSP API. Maybe we should define a formal BSP interface that cannot be touched without careful consideration?

[Sebastian Huber]

Replying to Chris Johns:

Replying to Sebastian Huber:

I am not sure what needs to be explained in more detail. This is mostly a mechanical change which just rearranges existing things a bit differently.

I think there are somethings, for example take "components are initialized on demand", what is a "component" and what does "initialized on demand" mean?

The two components are the workspace and the C program heap. On demand means that they are only initialized if functions of these components are used by the application.

I am OK with working through the detail but this will have to wait until I find the time. If you do not mind waiting let me know.

As usual, maintainers of BSPs which are not in the mainline RTEMS source have to pay a price and have to update their BSPs by themself. With an updated documentation, this shouldn't be an issue.

A number of users cannot submit their BSPs and we have attempted to maintain a BSP API. Maybe we should define a formal BSP interface that cannot be touched without careful consideration?

I do this with careful consideration. This change request is the result of a multi year work consisting of lots of small steps to make it possible to fully statically initialize RTEMS. Yes, it breaks the API, but adopting an existing BSP can be done easily in less than one hour. Also if you use a standard linker command file, then you can use the default implementation in your external BSP.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"1cb925717e77910ef5250c83e0d03f13285f33a8/rtems" 1cb9257/rtems]:

score: Add Memory Handler

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"c477d927e8578adfb35a77ff39542b96da7c2a37/rtems" c477d927/rtems]:

score: Add _Memory_Fill()

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"ffa11531700fca97a9be177bac54562de385401f/rtems" ffa1153/rtems]:

bsps: Add RamEnd? to linker command files

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"34a7a12f48b62f959029172d5e8ffbd2a73739d2/rtems" 34a7a12f/rtems]:

bsps: Add RTEMS_SYSINIT_BSP_EARLY

Add new BSP system initialization step for work to be performed before
the work areas are initialized.

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"c184b0cf3117c7872f465ef5e41aeb3fc65d1adb/rtems" c184b0c/rtems]:

stackchk: Add RTEMS_SYSINIT_ISR_STACK

Use a dedicated system initialization step for the stack checker
interrupt stack support.

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"07e2eacf8977121ef342e2d3c323ea6c997307b8/rtems" 07e2eac/rtems]:

bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

The code covered by BSP_GET_WORK_AREA_DEBUG was basically dead code
since there was no normal way to activate it (e.g. via a BSP
configuration option). A follow up patch will bring back this feature
through a CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION configuration option.

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"eea21eaca117ecd98afea164e1808d6530ef487f/rtems" eea21eac/rtems]:

bsps: Rework work area initialization

The work area initialization was done by the BSP through
bsp_work_area_initialize(). This approach predated the system
initialization through the system initialization linker set. The
workspace and C program heap were unconditionally initialized. The aim
is to support RTEMS application configurations which do not need the
workspace and C program heap. In these configurations, the workspace
and C prgram heap should not get initialized.

Change all bsp_work_area_initialize() to implement _Memory_Get()
instead. Move the dirty memory, sbrk(), per-CPU data, workspace, and
malloc() heap initialization into separate system initialization steps.
This makes it also easier to test the individual initialization steps.

This change adds a dependency to _Heap_Extend() to all BSPs. This
dependency will be removed in a follow up change.

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"f7c5f9436031702bb8cbc25bb54aad3d3425b028/rtems" f7c5f94/rtems]:

sysinit: Add RTEMS_SYSINIT_ORDER_LAST_BUT_[1-9]

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"c344e5828c3e8447a6164402f5786c8b0fbfb6a2/rtems" c344e58/rtems]:

Use RTEMS_SYSINIT_ORDER_LAST_BUT_5

Use RTEMS_SYSINIT_ORDER_LAST_BUT_5 instead of RTEMS_SYSINIT_ORDER_LAST
to allow applications and support functions to place system
initialization handlers behind the standard handlers.

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"813ada57f7efa3fb6a4a50616c4cd4abe45cec59/rtems-docs" 813ada5/rtems-docs]:

c-user: Update system initialization chapter

Update #2408.
Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"420525079c4b66025b1a924be13f29f54d288942/rtems-docs" 4205250/rtems-docs]:

bsp-howto: Rework system initialization chapter

Update #2852.
Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"ccaec9661f66089e45ee34c53ec4519e803fe444/rtems" ccaec966/rtems]:

libtests/malloc04: Fix typo

Update #3838.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"33d89aff99a01f970d03e4bc1a0d958b4c7db868/rtems" 33d89af/rtems]:

smpfatal09: Fix test case

Update #3838.