cFS, RTEMS, SPARC/LEON3 ensemble

[zureramad]

Hello everybody.

I have been looking for a bundle of cFS for RTEMS 5.1 in the SPARC/LEON3 BSP due to the general bundle only supports RTMS for PC platforms. The objective is to create an executable file which can be inserted in LEON3. I contacted @acudmore and he kindly pointed out three steps:

• A toolchain file for the SPARC/LEON3 architecture.
• A copy of the OSAL BSP so the pc-rtems specific code can be removed/changed.
• A copy of the PSP for pc-rtems so the pc-rtems specific code can be removed/changed.

I have already developed an alpha version of a toolchain which allows to compile and build cFS. I am using the RTEMS Cross Compiler (RCC) 1.3.0 which can be found in LEON/ERC32 RTEMS Cross Compilation System (RCC). The toolchain indicates the location of the RCC compiler, the file is added here as an example but, as mentioned before, it is an alpha an could have errors.

toolchain-sparc-rtems5.cmake.txt

When using the command make SIMULATION=sparc-rtems5 prep in the main cFS directory the build folder is successfully created.

However, is in the OSAL BSP and PSP configuration where I am more confused. I am aware that a new configuration in both cFS/osal/src/bsp and cFS/psp/fsw should be included called leon3-rtems. I will be glad if anyone could help me with the differences and changes that i should make in this new configuration in opposite to the pc-rtems one.

Thanks in advance. Jesús.

[ghost]

Hi Jesús,
I think you are on the right track. I use the same RCC 1.3.0 toolchain, so I know that the cFS will build and run on the LEON3 with it.

The OSAL BSP has the initial startup code for the cFS: When the pc-rtems OSAL BSP builds, you probably get errors because the LEON3 BSP does not have the IDE disk drivers.
You should copy the pc-rtems OSAL BSP as you suggested: leon3-rtems ( or you could call it generic-rtems, because it will likely run on additional RTEMS BSPS such as the Beaglebone black, etc )

OSAL BSP:
In the OSAL BSP , you will need to remove the code that mounts the IDE device, but you still need a file system to load the cFS apps, tables, and startup script. A generic way to do this on RTEMS is to use the IMFS Tar file system. This allows you to "tar" the contents of a directory, which can be then attached to the binary RTEMS image and "un-tarred" into the IMFS root file system when RTEMS boots. It's a great way to populate a file system when you do not have access to a disk device.

PSP:
in the PSP, I believe the only thing that is specific to the pc RTEMS BSP is the network device. Here you can change the network device to the GR ethernet device if you have one available on your target.

As a first step, you could try commenting out the IDE disk code in the OSAL BSP and the network initialization code in the PSP to see if you can create a cFE core binary that will load and run on your LEON3. It will report that it cannot find the cFE startup script to load apps, but that would be a good first goal.

Regards,
Alan

[jphickey]

Note - the "pc-rtems" BSP in OSAL is dependent on the "pc686" BSP as provided from the RTEMS source build. It is intended to allow the RTEMS build to be executed and tested on commodity x86 hardware. Symbols such as bsp_cmdline are provided by the pc686 bsp, and therefore would not be defined if you are not using this layer.

To run on another board, a comparable BSP will need to be implemented for that board. Starting with either pc-rtems or generic-linux is a good place to start but you'll have to "clone and own". In the first example it looks the config was changed to use a BSP called "generic-rtems" but the generic-rtems OSAL BSP was never actually defined - hence the non-existent target error.

If your intent is to make a generic-rtems BSP that works like the VxWorks, then "pc-rtems" is probably a good starting point, but you'll have to clone it, rename it, and remove all the stuff that is specific to and/or depends on the underlying "pc686" BSP from RTEMS.

[zureramad]

Hello,

I deeply appreciate you help. As it was proposed I have created an entire new build architecture for cFS for RTEMS and LEON3 target. Sorry for the delay but it took me a while.
Now I face the problem that I think Alan was mentioning in its first post, “It will report that it cannot find the cFE startup script to load apps”. Launching the executable in the LEON3 platform (I am using TSIM3 for this matter: TSIM3 ) I get the following error messages before the CFE enter the APPS_INIT and OPERATIONAL state:

OS_FileOpen_Impl():114:open(/mnt/eeprom/cfe_es_startup.scr): No such file or directory
1980-012-14:03:20.52182 CFE_ES_StartApplications: Error, Can't Open ES App Startup file: /cf/cfe_es_startup.scr, EC = -1

It seems like the startup file is not in the directory it should be. I have tried to change the directories in which cFS looks for the file (changing /mnt(eeprom to /cf or /ram in the cfe_psp_start.c) but the file does not seem to be in any of these directories. I guess that the differences between both directories (/mnt/eeprom and /cf) are not a problem because they are fixed-mapped physical and virtual directories.

How could I add the startup file to be found?

Thank you again for your help.
Greetings. Jesús.

[zureramad]

Hi all.
I just wanted to answer myself to close the discussion and maybe help the community. In its native build configuration cFS is configured to create different executables for the core and the applications. So, when running cFS in a different platform from the one compiled in you need to include, alongside with the main executable, the startup script and the other executable files .obj of the applications you desire in the project and allocate them in a known location.

This could be inadequate in case the hardware required only one binary file. That’s why cFS has the option of building the applications together with the main core executable in only one binary. It is done using the static app list instead of the in the targets.cmake config file.

However, it does not exist, or I have not been able to find a guide or tutorial that explains how to indicate to cFS that the applications that it must add and run are not found as files in a certain directory but included in the binary file itself. Applications added to this list of static applications should be initialized automatically, like dynamic ones, but cFS seems not to be designed this way.

Perhaps someone can enlighten us about it, but it may also be a reason to create another discussion.

I hope it is useful, greetings.

[jphickey]

You are correct in that the "static" app linkage is intended to address those use cases where the entire system needs to be contained in a single binary package, and/or where apps cannot be loaded from separate module files at runtime as usual. This permits all of the code to be loaded on the target as a single binary file.

The startup script is a bit of a problem, as it still (typically) must be loaded from a filesystem. To address this, there is an option to link the file directly with the executable via the EMBED_FILELIST directive in targets.cmake. This takes an arbitrary file from the dev host, and wraps the entire content into a C structure which is then linked into the binary. The idea is that during boot, this file can then be written to a RAM disk by the PSP, to be opened by CFE when needed. It works to get around the cfe_es_startup.scr problem if you do not have persistent storage.

It would be nice if OSAL could provide a file-like way of reading the file directly, rather than requiring it to be written to a RAM disk for this purpose, but that can be a future enhancement project for someone with time to implement this.

[ghost]

Another way to get files on an RTEMS target using a single binary is the RTEMS IMFS+Tar feature. This allows you to bundle a set of files in a tar file ( such as the startup script and tables) and RTEMS can unpack the tar file into the IMFS RAM file system when the system starts.
I have an example RTEMS application that does that here:
https://github.com/alanc98/rki2
It also has a LEON3 target that you can try.

The next question is:
How can you bundle the files you need in the cFE core when building the cFS tree?
I have taken the approach where I use the RKI project above as a "host" for the cFS, where the cFE core can be linked as part of this image. In this case, the cFE core needs to be an un-linked object that is either dynamically loaded in the RKI, or is linked directly to the RKI image.
It may be possible to just copy the relevant IMFS + Tar code and build rules into the RTEMS PSP so the tables, startup script and possibly even the apps are included in the Tar file. The only question is what comes first? The app and table builds, or the final link of the cFE core/RTEMS executable? If the apps and table are built before the cFE core is linked, this should work.
In the cFE core link:

• Copy app files (if using dynamic loading)
• Copy table files
• copy startup script
• create tar file
• convert tar file to binary object
• Perform final link of cFE core/RTEMS image

Also, a note for what @jphickey commented on with including files directly in the image, I have successfully used the RTEMS "untar" function on a different OS (FreeRTOS) where I was able to untar a set of files into a RAM disk. So perhaps that could be used in the OSAL and/or PSP in an OS agnostic way in the future. I believe the license of the untar code is permissive.

[skliper]

I've been looking into this and I've got a few related PR's I'm currently working on to integrate support. Look forward to some contributions in the near future. As of right now the rki2 is still separate (see Alan's link above), but cFS should support stand alone or loadable modules that work with it.

EDIT: see nasa/osal#1349
EDIT1: see nasa/PSP#376 (all this does is remove PC specific network setup so far)