s

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION

GODDARD SPACE FLIGHT CENTER

Operating System Abstraction Layer (OSAL)

Configuration Guide
582-2007-00
December 21, 2012 (Version 1.6)
Authors:

_______________________________________________ ________________
A. Cudmore/Flight Software Engineer/Code 582 Date

_______________________________________________ ________________
N. Yanchik/Flight Software Engineer/Code 582 Date

Approvals:

_______________________________________________ ________________
582 Branch Head Date

2
Acknowledgements

Revision History
Revision Release Changes to Prior Revision Approval
Number Date
1.0 10/17/07 Initial Release. A. Cudmore
1.1 02/13/08 Updates for RTEMS, Linux, and Cygwin for 2.11 release A. Cudmore
1.2 09/05/08 Updates for OSAL 2.12 release A. Cudmore
1.3 03/10/10 Updates for OSAL 3.1 release A. Cudmore
1.4 5/25/2011 Updates for OSAL 3.3 release A. Cudmore
1.5 12/13/2011 Updates for OSAL 3.4 release – added support for sis-rtems A. Cudmore
Removed cFE configuration text
1.6 12/21/2012 Updates for OSAL 4.0 release – Removed Cygwin and OS X A. Cudmore
configurations

3
 Table Of Contents
1   INTRODUCTION ................................................................................................................................... 5  
1.1   Scope .................................................................................................................................................. 5  
1.2   Background ........................................................................................................................................ 5  
1.3   Applicable Documents ....................................................................................................................... 5  
1.4   Acronyms ........................................................................................................................................... 5  
1.5   Glossary of Terms .............................................................................................................................. 5  
2   HOW TO CONFIGURE, BUILD, AND RUN THE OSAL ................................................................ 7  
2.1   Setup the Build Environment ............................................................................................................. 7  
2.1.1   Setup the OSAL Source Distribution .......................................................................................... 7  
2.1.2   Create System Environment Variable ......................................................................................... 8  
2.2   Configure the Build Directory for the OSAL application .................................................................. 9  
2.3   Configure the ‘build’ Directory ........................................................................................................ 10  
2.3.1   Define the CPU, Operating System, and Processor Board ....................................................... 10  
2.3.2   Configure the OSAL Parameter File ......................................................................................... 10  
2.4   Check over or customize the OSAL BSP directory ......................................................................... 12  
2.5   Configure one or more OSAL Applications .................................................................................... 12  
2.5.1   Configure a sample application in the build directory .............................................................. 12  
2.5.2   Configure the application’s main entry point ............................................................................ 12  
2.6   Build the OSAL core and Applications............................................................................................ 12  
2.7   Load and Run the OSAL Applications ............................................................................................ 14  
2.7.1   Load the OSAL Application Executable on the Target ............................................................ 14  
2.7.2   Setup the Target File Systems ................................................................................................... 14  
2.7.3   Start the OSAL Application on the Target ................................................................................ 15  
TARGET SPECIFIC INSTRUCTIONS .................................................................................................... 16  
2.8   Generic PPC / vxWorks 6.4 Platform: ............................................................................................. 16  
2.8.1   OSAL Configuration for the Generic PPC / VxWorks 6.4 ....................................................... 16  
2.8.2   File System Mappings on the MCP750 PPC Board .................................................................. 16  
2.8.3   How to run the OSAL Applications on the MCP750 or RAD750 ............................................ 16  
2.9   Axiom M5235 BCC / RTEMS 4.10: ................................................................................................ 18  
2.9.1   OSAL Configuration for the Axiom M5235 BCC / RTEMS 4.10 ........................................... 18  
2.9.2   File System Mappings on the Axiom M5235 BCC / RTEMS 4.10 .......................................... 18  
2.9.3   How to run the OSAL Applications on the Axiom M5235 BCC with RTEMS 4.10 ............... 18  
2.10   SPARC SIS Simulator / RTEMS 4.10: .......................................................................................... 19  
2.10.1   OSAL Configuration for the SPARC SIS Simulator / RTEMS 4.10 ...................................... 19  
2.10.2   File System Mappings on the SPARC SIS Simulator / RTEMS 4.10 .................................... 19  
2.10.3   How to run the OSAL Applications on the SPARC SIS Simulator with RTEMS 4.10 ......... 19  
2.11   PC / Linux Platform ....................................................................................................................... 20  
2.11.1   OSAL Configuration for the PC / Linux Platform .................................................................. 20  
2.11.2   How to Run the OSAL on the PC / Linux Platform ................................................................ 20  

4
1 Introduction
1.1 Scope

The purpose of this document is to provide guidelines and conventions for the configuration and
deployment of the Operating System Abstraction Layer (OSAL) to a desired platform or platforms.

1.2 Background

The goal OS Abstraction Layer is to promote the creation of portable and reusable real time embedded
system software. Given the necessary OS abstraction layer implementations, the same embedded software
should compile and run on a number of platforms ranging from spacecraft computer systems to desktop
PCs.

1.3 Applicable Documents

Document ID Document Title

1.4 Acronyms

Acronym Description
OS Operating System
API Application Programming Interface
CM Configuration Management
CPU Central Processing Unit
EEPROM Electrically Erasable Programmable Read-Only Memory
HW, H/W Hardware
RAM Random-Access Memory
SW, S/W Software
TBD To Be Determined

1.5 Glossary of Terms

The following table defines the terms used throughout this document. These terms are identified as proper
nouns and are capitalized.

Term Definition
Application A generic term for a computer program in a desktop or embedded system. An
(APP) Application is generally not part of the operating system.
Application
Programmer’s A set of routines, protocols, and tools for building software applications
Interface (API)
Board Support A collection of user-provided facilities that interface an OS and the cFE with a
Package (BSP) specific hardware platform. The BSP is responsible for hardware initialization.
Core Flight
A runtime environment and a set of services for hosting FSW Applications
Executive (cFE)

5
Cyclic
A polynomial based method for checking that a data set has remained unchanged
Redundancy
from one time period to another.
Check
Developer Anyone who is coding a software Application.
Hardware
The target hardware that hosts the an Operating System and Applications.
Platform
Interface Control A document that describes the software interface, in detail, to another piece of
Document software or hardware.
Any data being written to and read from an I/O port. No structure is placed on the
data and no distinction as to the type of I/O device. I/O data is defined separately
I/O Data
from memory data because it has a separate API and it’s an optional interface of
the cFE.
A collection of data that an application stores that provides information to
Log
diagnose and debug FSW problems.
Any data being written to and read from memory. No structure is placed on the
Memory Data
data and no distinction as to the type of memory is made.
Memory Management Unit. A piece of hardware that manages virtual memory
systems. It automatically translates addresses into physical addresses so that an
MMU
application can be linked with one set of addresses but actually reside in a
different part of memory.
Network A connection between subsystems used for communication purposes.
Platform See “Hardware Platform” above.
Anyone who interacts with the a Software Application or system in its operational
User
state. A user can be a developer, a tester, , an operator, or a maintainer.

6
2 How to Configure, Build, and Run the OSAL

The OSAL distribution includes a complete development environment with support for a number of
processors and operating systems. The OSAL development environment has been designed to isolate the
portable OS source code from the OSAL applications, configuration parameters, and build products. The
development environment is an example of how to configure and build portable software using the OSAL
code, but it is by no means a requirement to use the OSAL. The included platforms for the OSAL can be
used as starting points for other boards and CPUs.

The following sections provide instructions on how to:

• Setup the build environment

• Configure the build directory for an OSAL application
• Configure a OSAL Application
• Build the OSAL Application
• Load the OSAL Application on to the target platform
• Run the OSAL Application on the target platform

2.1 Setup the Build Environment

This section details the steps needed to setup the OSAL source distribution and prepare the host
development environment to build the OSAL.

2.1.1 Setup the OSAL Source Distribution

Get a copy of the OSAL source distribution directory on your build machine. The source distribution has
the following directories:
OSAL source distribution directories
Directory Description
osal The top level OSAL source distribution directory. OSAL version 2.10 is
being used as an example.
osal/src The src directory contains the OSAL source, and make rules.
osal/src/apps The apps directory contains the sample and test applications for the osal.
osal/src/bsp The bsp directory contains the platform specific code for the OSAL as well as
code to make the OSAL run on a particular platform. Everything in this
directory is used to adapt the OSAL and Applications to a particular hardware
platform. This directory also contains the startup code for the example
programs. The included platforms are generic enough that they may be easy
to port to other platforms and processor architectures. For example: The
bsp/mcf5235-rtems board support package was ported to an ARM processor
running RTEMS with minimal effort.
osal/src/make The make directory contains common makefiles for building the OSAL and
it’s applications.
osal/src/os The os directory is the heart of the OSAL, containing the implementation of
the OSAL for each supported operating system. There is a sub-directory for
each supported operating system in this directory. The OSAL include files are
also contained in this directory ( src/os/inc ).
osal/src/inc The inc directory contains system wide include files that are used by the
OSAL on all platforms.
osal/build The build directory contains a framework for building an OSAL application.

7
 The files in this directory allow easy customization and configuration for any
supported OS or platform for the OSAL. By changing two variables in a file,
the OSAL examples and test can be built for any of the supported platforms.
osal/doc The doc directory contains the documentation and release notes for the
OSAL.

The osal directory can go just about anywhere on a host development system.

Example directory structure locations

Host Operating Example Directory Notes
System
Windows/vxWorks 6 C:\osalproject\osal 1. Building on Windows with the vxWorks 6.x
Development Shell development tools requires using the “vxWorks
Development Shell”. The system will not build on
a standard Cygwin Shell, or a windows DOS
prompt.
Linux /home/osaluser/osal

2.1.2 Create System Environment Variable

The OSAL development environment requires one system environment variable to be set in order to build
the example programs. The directory also contains a shell script “[Link]” to set the environment to the
current OSAL directory.

Environment Variables needed by the cFE

Environment Variable Value (in Linux as an example) Notes
OSAL_SRC /home/osaluser/osal The location of the OS
Abstraction Layer source
code. This directory can be
moved anywhere as long as
the environment variable is
set accordingly.

Example Environment Variable for Different Development Hosts

Host Operating Example Environment Variables Notes
System
Windows/vxWorks 6 % set OSAL_SRC=C:/osalproject/osal 1. These environment
Development Shell variables can be set in
the Windows control
panel under
system/environment
variables.
2. Note the forward
slash directory
separators in the DOS
environment variables.
Because the vxWorks
tools are half DOS and
half-Unix, they don’t
seem to like the DOS
style backslash.
Linux $ export OSAL_SRC=/home/osaluser/osal These settings can be

8
 set in the user’s
.bash_profile

2.2 Configure the Build Directory for the OSAL application

The build directory is where the OSAL is configured and compiled for a particular processor, board, and
OS. The build directory is designed to hold the OSAL configuration for the selected platform. The core
directory is where the core OS code, and bsp code are built. They are left in the core directory for the
applications to link against. The build directory can have multiple OSAL applications to build for a
particular platform. The OSAL distribution contains directories for example and test applications. Multiple
build directories can be used to configure the OSAL for different platforms in the same environment, each
with it’s own unique OSAL configuration.

9
2.3 Configure the ‘build’ Directory

In order to build the OSAL for one of the supported platforms, the OSAL build directory must be properly
configured. This involves editing a couple of configuration files and setting up one or more sample
applications that use the OSAL API.

2.3.1 Define the CPU, Operating System, and Processor Board

In the build directory, edit the ‘[Link]’ file and set the options for your target. The default
settings in the [Link] are for running vxWorks6.4 on a generic PowerPC board.

[Link] Settings
[Link] variable Valid selections Notes
OS vxworks6, rtems, posix 1. VxWorks 5.5
is no longer
supported.
2. posix is tested
for 32 bit linux
2.6.x
BSP genppc-vxworks6.4, mac-posix, pc-posix, Use posix for
mcf5235-rtems, sis-rtems linux

Note that not all combinations are valid. See the Platform Specific Section for more information on each
supported cFE target.

2.3.2 Configure the OSAL Parameter File

The file osconfig.h has configuration parameters for tailoring the OSAL parameters. Most parameters set
upper bounds on the number of OS objects that can be created. The OSAL keeps track of allocated OS
objects using fixed size tables.

OSAL configuration parameters

Parameter Description
OS_MAX_TASKS The maximum number of tasks that can be
created in the running OSAL application.
OS_MAX_QUEUES The maximum number of queues that can be
created in the running OSAL application.
OS_MAX_COUNT_SEMAPHORES The maximum number of counting semaphores
that can be created in the running OSAL
application.
OS_MAX_BIN_SEMAPHORES The maximum number of binary semaphores
that can be created in the running OSAL
application.
OS_MAX_MUTEXES The maximum number of mutexes that can be
created in the running OSAL application
OS_MAX_PATH_LEN The maximum length for an absolute path length
in the OSAL File API.
OS_MAX_API_NAME The maximum length for an individual file name
in the OSAL File API.
OS_BUFFER_SIZE The maximum size of a formatted text message
for the OS_printf API.
OS_BUFFER_MSG_DEPTH The maximum number of messages buffered by

10
 the OS_printf API.
OS_UTILITY_TASK_ON Turns on a utility task that will read the
statements to print from the OS_printf function.
If this define is commented out OS_printf will
print the text under the context of the caller.
OS_UTILITYTASK_STACK_SIZE The size of the stack for the utility task.
OS_UTILITYTASK_PRIORITY The priority of the utility task.
OSAL_SOCKET_QUEUE If this is defined, the posix port will use the
socket implementation for message queues,
rather than the POSIX message queue
implementation. This needs to be defined for OS
X to work.
OS_MAX_MODULES Used for defining the maximum number of
loadable modules that the OS AL can keep track
of. This is used for the new Module Load and
Symbol API.
OS_MAX_SYM_LEN Used for setting the maximum length of a
symbol name in the symbol API.
OS_MAX_TIMERS Used for defining the maximum number of
timers in the OSAL.

11
2.4 Check over or customize the OSAL BSP directory

The glue logic that ties an OSAL application to a specific processor board and platform is in the src/bsp
directory. This directory contains the BSP code which contains all of the specific rules, glue code, and
startup code to make an OSAL application run on a particular board with a particular OS.
The platforms supported in the OSAL distribution should run out of the box. They provide a starting point
for a complete port to a new processor board.
This section will be expanded in the future to include information needed for new OSAL ports.

2.5 Configure one or more OSAL Applications

Once the OSAL is configured and ready to build, an OSAL application can be configured in the build
directory. Multiple OSAL applications can be created in this directory. The application source code can
come from the src/apps directory, or the applications can be contained completely within the build
directory. The OSAL source distribution has a set of test and example applications in the src/apps directory
and a set of corresponding application directories and makefiles in build directory.

2.5.1 Configure a sample application in the build directory

The following show the files needed for a sample OSAL application in the build directory.

Sample OSAL Applications and the associated files

File Description
build/example1 Directory for the included OSAL example
Application.
build/example1/Makefile Makefile for the example OSAL app. Because
the source is in the src/apps/example1 directory,
there is no need to include it here. The Makefile
will find it using the OSAL_SRC environment
variable. The source could be copied here in
order to customize it.
build/new_osal_app Directory for a new OSAL application.
build/new_osal_app/Makefile Makefile for a new OSAL application.
build/new_osal_app/new_osal_app.c Source file for the new OSAL application.
build/new_osal_app/new_osal_app.h Header file for the new OSAL application.

The Application Makefiles have a specific format, so it is best to copy one of the application Makefiles
from the build directory, such as build/example1.

2.5.2 Configure the application’s main entry point

The OSAL development environment provides the main entry point/startup code for the Application. This
code is located in the src/<bsp>/src directory. The startup code will call the Application’s entry point which
is named: void OS_Application_Startup(void)

2.6 Build the OSAL core and Applications

Once the OSAL Core and Applications are set up in a build directory, everything can be compiled. The
OSAL Core or any of the Applications can be built from individual make files, or they can be built from the
top-level Makefile in the build directory.

12
 Build Commands
Shell command Description
$ cd build Change to the build directory.
$ make Build the OSAL Core, and all Applications
$ make clean Clean the OSAL Core, and all Applications

$ cd core; make Build the OSAL Core files only.

$ cd example1; make Build the example1 Application only. NOTE: The OSAL Files have
to be compiled in order for the Application to link.
$ make depend Recalculate the dependencies on the OSAL Core files and apps

Once the OSAL Applications are built, they are ready to load and execute on the target. The filename of the
executable is dependent on the OS it is built for.

OSAL Application executable name

Target Operating System Application executable Notes
name
vxWorks 6.x dynamic link [Link] The vxWorks PowerPC platforms use a
dynamically loaded object without the
kernel.
Linux [Link]
Rtems/Coldfire [Link] This is a static linked executable, linked
with the RTEMS kernel and BSP.
RTEMS/SIS [Link] This is a static linked executable, linked
with the RTEMS kernel and BSP.

13
2.7 Load and Run the OSAL Applications

Depending on the Target, it is usually straightforward to run an OSAL Application on a target platform. On
desktop platforms, it is just a matter of running the executable program. On vxWorks, the example
programs are loadable modules.

2.7.1 Load the OSAL Application Executable on the Target

On desktop targets the cFE Core can be run from the directory where it was compiled. On embedded
targets, the Application has to be loaded into a remote file system, or booted over the network. On the
vxWorks PowerPC targets, the Application can be loaded into the EEPROM or Flash disk after the
vxWorks kernel is booted. On RTEMS targets, the Application can be loaded using the CEXP dynamic
loader or it can be linked in with an RTEMS Binary. See the target specific sections for details on each
platform.

2.7.2 Setup the Target File Systems

Because the OSAL runs on many different platforms, it must be able to deal with different file system types
and different paths. The OSAL accomplishes this by using a file system abstraction. The abstracted OSAL
file system is similar to a UNIX file system, where the root directory starts with “/” and all disks are
mounted on directory trees. For example:
• /ram0/apps/ à RAM disk 0, apps subdirectory
• /ram1/data/ à RAM disk 1, data subdirectory
• /hd0/tables/ à Hard Disk 0, tables subdirectory
Using this abstraction, a file “[Link]” on RAM disk 1 might be accessed from the OSAL by using the
path “/ram1/data/[Link]”. Using the host vxWorks tools, the path to the same file would be:
“RAM:0/data/[Link]”. If the OSAL is running on a Linux development workstation, the file might be
located at: “/tmp/ramdev1/data/[Link]”. The important part is that the OSAL Application can access
the files using a generic path, allowing the software to remain portable.

There are a few ways to map these host file systems to OSAL file systems:
• Map existing target file systems to a OSAL path. This is one of the most common ways to map
the Non-Volatile disk to the OSAL. The OSAL relies on the target OS to create/mount a file
system and it simply is given a mapping to the disk to allow the OSAL to access it.
• Create EEPROM/Flash/ATA File systems. The OSAL has the ability on some targets to format
or initialize a EEPROM or ATA disk device. This is less commonly used.
• Create RAM File Systems. The OSAL can create RAM disks on the vxWorks targets. The OSAL
will create or re-initialize the RAM disk for the vxWorks targets.

RTEMS Note: The RTEMS OS provides a base file system, called IMFS that provides the root directory.
Because this closely matches what the OSAL file system abstraction provides, the RTEMS directories and
filenames are a one to one mapping. In other words the path on RTEMS is the same as the path in the
OSAL.

14
The following table shows examples of these file system mappings on various hosts. Note the change in the
way the POSIX ports are mapped. Linux will no longer remove or create sub-directories based on the
volume name. The path mapping for the FS_BASED option is now a simple mapping from an OSAL path
to a host path. This makes the OSAL easier to use on linux platforms:

OSAL File system mapping

Target Operating cFE File system path Target OS Notes
system File system
path
vxWorks 6.x /ram RAM:0/ Most vxWorks targets

/cf CF:0/ or CF:1/ MCP750

/cf EEP:0/ RAD750 target
Linux /ram ./ram0 Note the “.” This will map
the RAM disk to the current
working directory + the
“ram0” subdirectory.
/cf ./cf Again, starts with the current
working directory.
RTEMS /ram /ram RTEMS has 1-1 mapping
with the OSAL
/cf /cf

2.7.3 Start the OSAL Application on the Target

Starting an OSAL Application is a highly target dependant activity. The following table gives examples of
how to start an Application on various platforms. For full details see the notes for each section.

How to start an OSAL Application on Various Target Systems:

“Target” operating system How to start the cFE
RTEMS / mcf5235 Loaded through GDB/BDM using a shell script: “[Link]”
RTEMS / SIS Loaded through GDB/SIS simulator:
$ sparc-rtems4.10-gdb [Link]
(gdb) target sim
(gdb) load
(gdb) run
vxWorks 6.2 / RAD750 Started from the vxWorks Target Shell commands:
Vx> ld < [Link]
Vx> OS_BSPMain
Linux Start directly from the linux shell:
$ ./[Link]

15
Target Specific Instructions
This section provides details on how to load and run each of the supported OSAL configurations.

2.8 Generic PPC / vxWorks 6.4 Platform:

The Generic PPC applications will work on both the Motorola MCP750 and the BAE RAD750 running
vxWorks 6.4. On this platform, the OSAL Applications are built as dynamic loadable vxWorks modules,
rather than being linked to the vxWorks kernel/BSP. The OSAL Applications are loaded into the compact
flash disk on the MCP750, so it can be started from a vxWorks shell or startup script after the kernel comes
up.

2.8.1 OSAL Configuration for the Generic PPC / VxWorks 6.4

[Link] Settings
[Link] variable Required selection Notes
OS vxworks6
BSP genppc-vxworks6.4

2.8.2 File System Mappings on the MCP750 PPC Board

The cFE uses the following file system mappings for the MCP750 PPC Board. The file system mappings
are defined in the bsp_voltab.c file in the src/arch/ppc/genppc/vxworks6.4/bsp directory:

OSAL File System Mappings

OSAL File System Type OSAL Path Host Path Notes
“device”
/ramdev0 Real RAM Disk ( /ram RAM:0/
vxWorks )
/eedev0 File System Mapped /cf eep:0/ This is the Compact Flash drive on the
(FS_BASED) MCP750
/ramdev1 – Real RAM Disk N/A N/A Unused table entries for applications to
/ramdev5 create new RAM disks
/ssedev0 - File System Mapped N/A /ssr:0/SSR1 Unused table entries for applications to
/ssrdev2 (FS_BASED) - map Hard Disk device directories to
/ssr:0/SSR3 “pseudo” SSR file systems.

2.8.3 How to run the OSAL Applications on the MCP750 or RAD750

1. Load the kernel. The custom vxWorks kernel is loaded into the MCP750 via TFTP. We use a vxWorks
boot image (Rather than the Motorola boot monitor/loader ) to boot the MCP750 board, TFTP the “real”
kernel to RAM, and execute it. This vxWorks boot image also sets the network settings for the “real”
kernel image. On our OSAL/cFE development system, we keep the loadable vxWorks kernel image in a
TFTP directory on the development workstation. So the vxWorks kernel image goes in
/tftpboot/cpu1/[Link]. ( $ cp /opt/workspace/mcp750image/default/vxWorks
/tftpboot/cpu1/[Link] )

16
2. Copy the “[Link]” ( or other executable name ) loadable module into the non-volatile disk. On the
MCP750, this is done simply by FTPing the [Link] file to the target:
$ ftp [Link]
ftp> username: target
ftp> password: password
ftp> cd “CF:0”
ftp> binary
ftp> put [Link]

3. Load the example Application in the vxWorks shell:

vx> cd “CF:0”
vx> ld < [Link]

4. Run the example Application in the vxWorks shell:

vx> OS_BSPMain
( The entry point for the examples and test programs is always OS_BSPMain )

17
2.9 Axiom M5235 BCC / RTEMS 4.10:

The OSAL supports the Axiom 5235 BCC single board computer with an RTEMS 4.10 board support
package. The 4.10.2 version of RTEMS was used (as of December 2012) along with the RTEMS 4.10
compiler for the m68k/coldfire. The tests and examples are built as static RTEMS executable programs for
the board and can be loaded using the DBUG monitor or BDM port. When developing for RTEMS, the
libraries and BSP code is usually located in /opt/rtems-4.10. The OSAL Makefiles use an environment
variable “RTEMS_BSP_BASE” to determine where the RTEMS libraries and BSPs are installed. This
variable is set from the “[Link]” file along with an example of how to set the variable..

2.9.1 OSAL Configuration for the Axiom M5235 BCC / RTEMS 4.10

[Link] Settings
[Link] variable Required selection Notes
OS rtems
BSP rtems-mcf5235

2.9.2 File System Mappings on the Axiom M5235 BCC / RTEMS 4.10

The RTEMS port of the OSAL has a one to one file system mapping. The OSAL RAM disk will format an
RTEMS NVRAM disk with the RFS file [Link] file system mappings are defined in the bsp_voltab.c
file in the src/bsp/mcf5235-rtems/src directory:

OSAL File System Mappings

OSAL File System Type OSAL Path Host Path Notes
“device”
/ramdev0 RAM_DISK ( /ram /ram Mapped to the IMFS root directory
NVRAM/RFS )
/eedev0 File System Mapped /cf /cf Mapped to the IMFS root directory
(FS_BASED)
/ramdev1 – Unused N/A N/A Unused table entries for applications to
/ramdev5 create new RAM disks. RTEMS does
not currently have support for creating
new RAM disks.
/ssedev0 - File System Mapped N/A N/A Unused table entries for applications to
/ssrdev2 (FS_BASED) map Hard Disk device directories to
“pseudo” SSR file systems.

2.9.3 How to run the OSAL Applications on the Axiom M5235 BCC with RTEMS 4.10

When the example application and test programs are all built as static executables for the M5235BCC
board. The example programs can be loaded in the following ways:
Using the BDM port through the GNU debugger. If the board is connected to the host PC with a BDM
debugger cable, then the example programs can be loaded and run from there. For our environment we use
the Gnu Debugger that was included with the RTEMS 4.10 tools and the m68k-bdm-gdbserver from the
BDM Tools project: [Link] . The gdb-init script and a [Link] file are included in
the src/bsp/mcf5235-rtems/bsp/rtems-support directories. The [Link] script gives the proper command
line to load the application to the board using the GDB debugger and BDM interface.

18
2.10 SPARC SIS Simulator / RTEMS 4.10:

The OSAL supports the SPARC SIS simulator built into GDB with the sis RTEMS 4.10 board support
package. The 4.10.1 version of RTEMS was used (as of December 2011 ) along with the RTEMS 4.10
compiler for the sparc. The tests and examples are built as static RTEMS executable programs for the
simulator. The OSAL Makefiles use an environment variable “RTEMS_BSP_BASE” to determine where
the RTEMS libraries and BSPs are installed. This variable is set from the “[Link]” file along with an
example of how to set the variable.

2.10.1 OSAL Configuration for the SPARC SIS Simulator / RTEMS 4.10

[Link] Settings
[Link] variable Required selection Notes
OS rtems
BSP sis-rtems

2.10.2 File System Mappings on the SPARC SIS Simulator / RTEMS 4.10

The RTEMS port of the OSAL has a one to one file system mapping. The OSAL RAM disk will format an
RTEMS NVRAM disk with the RFS file system. The file system mappings are defined in the bsp_voltab.c
file in the src/bsp/sis-rtems/src directory:

OSAL File System Mappings

OSAL File System Type OSAL Path Host Path Notes
“device”
/ramdev0 RAM_DISK ( /ram /ram Mapped to the IMFS root directory
NVRAM/RFS )
/eedev0 File System Mapped /cf /cf Mapped to the IMFS root directory
(FS_BASED)
/ramdev1 – Unused N/A N/A Unused table entries for applications to
/ramdev5 create new RAM disks. RTEMS does
not currently have support for creating
new RAM disks.
/ssedev0 - File System Mapped N/A N/A Unused table entries for applications to
/ssrdev2 (FS_BASED) map Hard Disk device directories to
“pseudo” SSR file systems.

2.10.3 How to run the OSAL Applications on the SPARC SIS Simulator with RTEMS 4.10

When the example application and test programs are all built as static executables for the SIS Simulator
built into the sparc-rtems4.10-gdb executable.
To run an example or test, simply do the following:

$ sparc-rtems4.10-gdb [Link]
(gdb) target sim
(gdb) load
(gdb) run

When you are finished running/debugging, hit <ctrl>-c and quit the debugger.

19
2.11 PC / Linux Platform

The OSAL can run on linux distributions. Testing is done with CentOS 5.5 32 bit. Newer versions of the
Linux 2.6 kernel have POSIX message queues, which can be used for the OSAL Queue implementation. If
the POSIX message queues are not available, then the OSAL Queues will use UDP sockets. ( see the
OS_SOCKET_QUEUE configuration parameter ). In general, the older versions of linux ( 2.4 kernel ) are
not supported. In addition, the OSAL has only been tested on 32 bit versions of Linux.

2.11.1 OSAL Configuration for the PC / Linux Platform

[Link] Settings
[Link] variable Required selection Notes
OS posix
BSP pc-linux

Additional configuration notes:

To enable the POSIX message queues, make sure the OS_SOCKET_QUEUE parameter is not defined in
osconfig.h.
If the OS_SOCKET_QUEUE option is not used, the OSAL will use POSIX message queues. If POSIX
message queues are used, your application may need to run as root in order to create the queues you need.
There are kernel parameters that can be adjusted in order to avoid running as root.

2.11.2 How to Run the OSAL on the PC / Linux Platform

1. To run an OSAL Application, simply execute the binary from a shell prompt:

build/example1]$ ./[Link]

20