Upcoming RTEMS updates for cFS

[ghost]

Hi Everyone,

Here is a description of upcoming RTEMS updates I am working on. There are a lot of variations with the different RTEMS versions, targets, and ways that cFS can be deployed on them. This work is an effort to provide a minimal set of updates that enable:

• Use of the Gaisler RCC toolchain
• Microblaze and Aarch64 targets that require RTEMS 6
• Building the cFE core as a loadable module, similar to how we build the cFE core for VxWorks

Part 1:
I first plan on supporting RTEMS 6 with the existing pc-rtems platform and CI workflows:

OSAL part 1

• Building without a network stack: Add os-impl-no-select.c for operating systems that do not have select (RTEMS 6 with network off) osal#1248

cFE Toolchain files / sample_defs

• Add a i686-rtems6 toolchain file
• i686-rtems4.11 and i686-rtems5 toolchain files - Reorder, and add a BSP specific specs flag
• Update RTEMS toolchain files for RTEMS 4.11, 5, and 6 cFE#2096

CI workflows

• Add a RTEMS 6 container and the workflows to test pc-rtems like the 4.11 and 5 workflows
• Add RTEMS 6 container for cFS RTEMS workflows core-flight-system/containers#11
• Pull Request for RTEMS 6 container: Fix #11, Add RTEMS 6 container for cFS test workflow core-flight-system/containers#12

PSP

• RTEMS.cmake platform file - Support dynamically loaded cFE core (similar to vxworks). This will co-exist with the current executable rule that is used in the pc-rtems platform
• RTEMS.cmake platform file - Factor the bsp specs to support RTEMS 6 and Gaisler RTEMS toolchain differences
• Issue here: Support RTEMS 6, Gaisler RCC, and Dynamically loaded cFE build in RTEMS.cmake platform file PSP#338

OSAL part 2

• OSAL Core - Support RTEMS 6
• OSAL BSP - pc-rtems support for RTEMS 6
• Add OSAL support for RTEMS 6 osal#1256

CI Workflow Part 2

• Update cFS bundle workflow to build and test on RTEMS 6

Part 2:
After that work is complete, I would like to add a generic-rtems platform:

• A new generic-rtems OSAL BSP
• A new generic-rtems PSP
• Add Gaisler RCC toolchain file(s)
• Add RTEMS 6 Microblaze/Sparc/Aarch64 toolchain files
• CI support for the generic-rtems platform

Thanks!
Alan

[ghost]

First issue - Add os-impl-no-select.c which is needed by RTEMS 6 (or really any RTEMS version) when building without a network stack:
nasa/osal#1248

It can go in first, because it does not depend on a specific RTEMS version

[ghost]

For toolchain updates, @jphickey recommended using clearer defines to identify the RTEMS build:

• RTEMS 4.11 - OS_RTEMS_4_DEPRECATED
• RTEMS 5 - OS_RTEMS_5
• RTEMS 6 - OS_RTEMS_6

instead of "_RTEMS_5_" which could be confused with a built-in/compiler define. I think this is a good idea.

The next PR will add:

• OS_RTEMS_4_DEPRECATED
• OS_RTEMS_5 (keeping the existing one until the OSAL/PSP changes are in)

Future toolchains for RTEMS 6 will have:

• OS_RTEMS_6

I would also like to add a define to indicate that the cFE core should be built as a dynamically loaded module vs. statically linked as an RTEMS executable (as is done with the pc-rtems platform). My current prototype has this in the toolchain file:
set(RTEMS_DYNAMIC_LOAD 1)
Not being a Cmake expert (or even novice), is this OK? Should I use TRUE and FALSE instead?
Another thought:
Instead of having the conditional CMAKE EXE rule in the platform RTEMS.cmake file, should we (or do we) have a way to indicate that the cFE core is a dynamically loaded module, or that it should be linked with the OS runtime/startup code as it is in pc-rtems?

Finally, the RTEMS.cmake platform file has a RTEMS_SYS_SPECS_FLAGS define that sets up the BSP specs for GCC. For compatibility with RTEMS 5, RTEMS 6, and the Gaisler RCC toolchain, I factored out a portion of this to RTEMS_BSP_SPECS and put it in the toolchain.
Is RTEMS_BSP_SPECS a good name, or should it be RTEMS_TOOLCHAIN_SPECS?
Examples in the toolchain file are:
Gaisler RCC 1.3 toolchain: set(RTEMS_BSP_SPECS "-qbsp=${RTEMS_BSP}")
RTEMS 4 and 5: set(RTEMS_BSP_SPECS. "-specs bsp_specs")
RTEMS 6: Not necessary

To summarize, I would like to add toolchain defines:

• A RTEMS version define
• A dynamic load define
• A Toolchain specific BSP Specs define

Thoughts?

[jphickey]

With respect to the underscores, it's actually called out in C99 (ISO/IEC 9899, section 7.1.3 "Reserved identifiers") that all identifiers that begin with an underscore are considered reserved. So it's not just a personal preference thing ... its technically wrong/violation of the spec to define anything in application code that starts with an underscore, although I've never seen it enforced or cause a problem - nonetheless, we should try to get away from doing this.

With respect to dynamic loading, I think we should actually move toward this model always. Linking as a monolithic/static kernel+app makes it easier to run the tests - because we can run QEMU and boot the kernel and app in one shot. But, we may be able to accomplish something similar by just having some bootstrap code that loads the image after boot.

I generally buy into the theory of "test what you fly" in that we should strive to keep the testing environment as close to the real deployment environment - so real deployments are building separate CFE core images then it's not a bad idea to move testing to that model too, rather than testing in an environment that isn't really representative of how the software is deployed. Furthermore, we can also move "pc-linux" to that model too, where CFE core is a separate .so file, and the "core-cpuX" executable is just a small bootstrap program to load the modules and branch to the PSP entry point.

All that is a bigger change - so for now we might need to keep RTEMS_DYNAMIC_LOAD as you have it, but for future roadmaps I'd like to see this go away and just be the only way to build it, rather than an option - this would also reduce technical debt of the build system by not having to support two different ways of linking things, and not abusing the idea of what cmake calls an "executable", among other things.

As for the "specs" handling, it seems OK to me ... it is tied to the choice of BSP, so RTEMS_BSP_SPECS seems appropriate ... though I don't have any real strong opinion on the matter. It sounds like you've identified a split that permits the RTEMS 4/5/6 as well as the Gaisler toolchains to all work correctly, so that sounds good to me.

[ghost]

Thanks for the feedback, and clarification on the reserved identifiers!