rtos: Improve CMSIS-RTOSv2 app compatibility

[Patater]

Summary of changes

Some non-Mbed-OS, pre-existing CMSIS-RTOSv2 applications depend on
CMSIS-RTOSv2 Automatic Dynamic Allocation, also known as Object-specific
memory pools. Mbed OS doesn't by default provide any memory to the
CMSIS-RTOSv2 Automatic Dynamic Allocation pool, as doing so would waste
memory if the feature is not used; even if the feature is used, as a
platform, Mbed OS can't know how many objects of which types will be
created by an application and therefore will either waste memory or not
provide enough memory in a hard to debug manner. Portable CMSIS-RTOSv2
applications depending on CMSIS-RTOSv2 Automatic Dynamic Allocation
should instead configure the memory pools themselves, as applications
know best their memory requirements.

Add Mbed configuration options which can be used by applications to
control the amounts of memory available to the CMSIS-RTOSv2 Automatic
Dynamic Allocation subsystem. This enables portable CMSIS-RTOSv2
applications, which can run on any CMSIS-RTOSv2 OS, to be able to run on
Mbed OS as well.

Signed-off-by: Devaraj Ranganna [email protected]
Signed-off-by: Jaeden Amero [email protected]

Impact of changes

Applications written for CMSIS-RTOSv2 that use CMSIS-RTOSv2 Automatic Dynamic Allocation can now also run on Mbed OS, when the application specifies how much memory to use in their mbed_app.json. CMSIS-RTOSv2 docs claim that Automatic Dynamic Allocation is "fully portable", and now that's at least more true than before where Mbed is concerned.

The TF-M regression tests are a concrete example of an application written making use of CMSIS-RTOSv2 Automatic Dynamic Allocation. We have an incredibly easier time running (and maintaining) those tests with Mbed OS, validating the TF-M integration with Mbed OS does not break TF-M functionality, when Mbed OS supports application-configured CMSIS-RTOSv2 Automatic Dynamic Allocation.

Migration actions required

None

Documentation

We should document how to specify this memory in mbed_app.json. No doc PRs have been raised yet.

---

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

TODO
We probably should add tests before merging this.

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@bulislaw

---

[ciarmcom]

@Patater, thank you for your changes.
@bulislaw @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

[kjbracey]

I can see this could be useful.

Hmm, I wasn't actually aware of the existing options there following that naming pattern. "app" config options are supposed to be config options for the application, not the OS. The existing ones seem to be written as "if app.idle-thread-stack-size exists use it, else use rtos.idle-thread-stack-size".

That's weird. Applications should be overriding rtos.idle-thread-stack-size. @0xc0170, got any idea of the history of that? Is it backwards compatibility?

So can I suggest you ignore the "app" options, and just put them as "rtos" ones, so in rtos/source/TARGET_CORTEX/mbed_lib.json. Set the defaults there as 0, and code like

#if MBED_CONF_RTOS_MUTEX_NUM != 0
#define OS_MUTEX_OBJ_MEM    1
#define OS_MUTEX_NUM        MBED_CONF_RTOS_MUTEX_NUM
#endif

Not 100% happy with the name rtos.mutex-num, but at least it matches RTX, and not found any pattern I'm happier with,

[urutva]

@Patater @kjbracey-arm
I agree. I makes more sense to have a configurable rtos parameter than adding application specific config to rtos.

[0xc0170]

That's weird. Applications should be overriding rtos.idle-thread-stack-size. @0xc0170, got any idea of the history of that? Is it backwards compatibility?

Is this reffering to if app config present use it otherwise default to rtos config ? Isn't this how config works, set this value in the config in app, MBED_CONF_APP created so would need to overwrite what is set in MBED_CONF_RTOS one ?

[kjbracey]

MBED_CONF_RTOS_XXX refers to an option called xxx defined in the config section of an mbed_lib.json with name rtos.

MBED_CONF_APP_XXX refers to an option called xxx defined in the config section of mbed_app.json.

An app should be flipping the default for system components by doing the "target_overrides" "*" for "rtos.xxx" in their mbed_app.json, which would change MBED_CONF_RTOS_XXX

System components shouldn't be looking at application configuration options - they should be for the application code itself (eg configuring server address to connect to, or which LED to blink, or something).

[mbed-ci]

Test run: FAILED

Summary: 3 of 3 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-ARM-lts
• jenkins-ci/mbed-os-ci_build-GCC_ARM-lts
• jenkins-ci/mbed-os-ci_unittests-lts

[0xc0170]

Please ignore lts jobs here , not valid for this PR. We will restart testing and fix lts status here later once 5.15 jobs are in

System components shouldn't be looking at application configuration options - they should be for the application code itself (eg configuring server address to connect to, or which LED to blink, or something).

we know what should be updated here now

[Patater]

Rebased to:

• Add more object types. All CMSIS-RTOSv2 dynamic object types are configurable.
• Update rtos/source/TARGET_CORTEX/mbed_lib.json with descriptions of the configuration options.
• Use rtos rather than app in the configuration option names.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 6 of 6 test jobs passed
Build number : 1
Build artifacts