[okl]

While smaller ESA projects like satellite instruments are usually free to choose which version of RTEMS they use, larger and more important projects use ESA's own version. This version is known as the "EDISOFT" version because it was re-developed/qualified by a portuguese company of that name. It is basically a rewrite of a subset of the RTEMS API. You can read more about it here: https://www.esa.int/Enabling_Support/Space_Engineering_Techn...

Like most of ESA's software engineering tools, it is hopelessly outdated and relies on a patched GCC 4.2.1 which is missing a lot of useful features and bug fixes, especially for the SPARC architecture which is often used in ESA spacecraft. See -mfix-* switches here https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options....

While RTEMS is GPL-licensed ESA does not want the code to be freely available -- you probably won't find it online. Some years ago they realized that, if they don't upstream their code, they have no chance to keep up to date and started an initiative to improve the situation: https://rtems-qual.io.esa.int, https://rtems-qual.io.esa.int/

[JoelSherrill]

This is ESA's fourth RTEMS qualification effort AFAIK. This time they are working with the community and have submitted things like requirements for a subset of RTEMS and requirements based tests. This is tracking the git master and SMP is included. We worked with NASA IV&V folks to get an outline for the RTEMS Software Engineering Guide which provides information expected in a qualification review.

Quietly an RTEMS core developer submitted GCC support for running gcov or gprof on embedded targets and getting the information off. This will be used to get coverage reports which meet ESA expectations. We do have very high code coverage.

ESA has also sponsored formal analysis of some parts of RTEMS.

I am quite happy ESA is working so well with our core developers and community this time.

[vodou]

I am trying to understand what differs the EDISOFT and upstream versions of RTEMS. The only concrete differences I can read out from the linked webpage is basically:

* SpaceWire support (LEON3)

* MIL-STD-1553 support (LEON3)

* kernel and application monitoring services (whatever that means)

Do you know any other differences?

[okl]

Basically they made a list of a minimal set of functions that they want to support. They deleted all the other functions, then re-implemented the remaining code. For example, they axed the entire POSIX API, only kept the classic "rtems_" API. I don't know about quality of the SpW and M1553 code in the EDISOFT version but the quality of the driver code that Gaisler (now CAES) distributes for their processors is abysmal. Found here: https://www.gaisler.com/anonftp/rcc/src/ -- Among other issues: spaghetti-code, certain error flags not checked/reset resulting in lockups in case of errors, buffer sizes not configurable, unbounded loops/excessive wait delays. All big no-nos for safety-critical embedded software but understandable given limited manpower.

[inamberclad]

I believe RTEMS is BSD licensed.

[okl]

Nope, it's not. At least not entirely: https://www.rtems.org/license -- and the ESA version is definitely GPL-licensed.

Nothing against you personally, but I would really appreciate if instead of stating a certain believe, you actually look it up and point out a source for that bit of information.

[LouisvilleGeek]

The project is moving to a two paragraph BSD license and is making great progress.

https://devel.rtems.org/ticket/3053