Summary

This wiki describes how to configure OpenArbor as an aid during component and component test development. Formal build and test activities must follow the HowTos.

The information within this wiki assume the following:

The component is already checked out from subversion. The steps assume an imaginary project named "deos653p1"
You will replace the <projectName> with the appropriate project name. Example: deos653p1 or deos653p1-test

Additional OpenArbor resources

Please refer to the OpenArbor User Guide (found in your desk) for general information about setting up and using the OpenArbor tool.

Create a New Project

Preconditions

Version 13.0.0 (or newer) of OpenArbor. For prior versions, see the #OpenArbor version 12.6.0 and Earlier section.
Please refer to the readme.txt file associated with the component for additional details about building the component.

Existing OA Project

If your component was previously created in OA, then you can use these abbreviated steps. If this does not apply, then skip to the #New OA Project section below.

NOTE: You can only use these steps if you are using the EXACT path that you used previously when the project was built. The OA tool creates a set of hidden files that are stored in the component's folder, and these hidden files can be re-used by following these steps (and save you some time in creating a new project).

File → New → DDC-I Deos Makefile Project with Existing Code
1. Name : <projectName>
2. Uncheck the "Import Source Code from a Zip file"
3. Use the Browse... to navigate to the appropriate Existing Code Location. Examples:
  - Component: ~/scm/Deos/products/arinc653/runtime/branches/mainline
  - Test component: ~/scm/Deos/products/arinc653/runtime/branches/mainline/tests
4. Select "Finish"

New OA Project

File → New → Project → C/C++ → C/C++ Project
1. Select Next
2. Select C++ Managed Build
3. Select Next
4. Project name: <projectName>
5. Uncheck "Use default location"
6. Use the Browse... to navigate to the appropriate code location. Examples:
  - Component: ~/scm/Deos/products/arinc653/runtime/branches/mainline
  - Test component: ~/scm/Deos/products/arinc653/runtime/branches/mainline/tests
7. Project type: Makefile project → Empty Project
8. Toolchains: -- Other Toolchain --
9. Select "Finish"
Project properties → C/C++ Build
1. "Builder Settings" tab
  1. Unselect the checkbox "Use default build command"
  2. Build Command: bash
2. "Behavior" tab
  - Component:
    1. Select "Use custom build arguments"
    2. Build arguments: common/build-utils/build
    3. Build (Incremental build): install
    4. Clean: -c
    5. Select "Apply"
  - Test:
    1. Select "Use custom build arguments"
    2. Build arguments: common/test-utils/regress
    3. Build (Incremental build): -q <projectName> so qemu-arm build
    4. Clean: reallyClean
    5. Select "Apply"
Project properties → C/C++ General → Paths and Symbols

"Includes" tab (if you have a saved Paths and Symbols file (see step d. below))
1. Select Import Settings
2. Use the Browse... button to navigate to where you saved your Paths and Symbol file
3. Skip to step e. (Source Location Tab)

"Includes" tab (if you do not have a saved file for the Paths and Symbols)

GNU C++, Add...
Select the "Add to all configurations" and the "Add to all language" checkboxes

Paths for using File System... (IN THIS ORDER)

Component	Test
`${ProjDirPath} ${DESKHOME}/arm/include ${DESKHOME}/include ${DESKHOME}/include/sys`	`${ProjDirPath} ${DESKHOME}/arm/include ${DESKHOME}/include ${DESKHOME}/include/sys` `${DESKHOME}/src/test-component`

NOTE: When using OpenArbor in a Cygwin environment, the above paths must use "\" instead of "/".

"Symbols" tab
NOTE: These are needed by the OpenArbor environment to resolve many syntax warnings within the editor.
1. GNU C++, Add...
2. Select the "Add to all configurations" and the "Add to all language" checkboxes
  Enter the following Name/Value:
  
  Name Value
  
  __GNUC__ 11 (see Note 1 below)
  
  __SIZE_TYPE__ unsigned int
  
  __PTRDIFF_TYPE__ int
  
  Add one of the following symbols (using the same approach as described above) based upon the target architecture:
  
  Name Value
  
  __aarch64__ 1
  
  __arm__ 1
  
  __PPC__ 1
  
  __x86_64__ 1
3. Select "Apply"
  Note 1: If using an older version of gcc (such as version 7), then use the corresponding version number for the GNUC entry
  Note 2: The list above my not be sufficient. Please use the following command to get a complete list:
  echo | arm-eabi-gcc -E -dM -
"Symbols" tab (to export your paths and symbols)
1. Select the "Export Settings" button
2. Use the "Browse..." button to navigate to the directory you want to save the Paths and Symbols. It is suggested you use a location that you will remember such as your "home" folder.
3. Enter a Name (e.g. oa_paths_and_symbols.xml)
4. Select Save
5. Select Finish
"Source Location" tab
1. Expand project and select "Filter"
2. Select "Edit Filter"
3. Select "Add Multiple"
  - Component: select "docs", "output", "process", and "tests"
  - Test: select "docs", "output", and "results"
4. Select "OK" and "OK"
5. Select "Apply and Close"

Name	Value
`__GNUC__`	`11` (see Note 1 below)
`__SIZE_TYPE__`	`unsigned int`
`__PTRDIFF_TYPE__`	`int`

Name	Value
`__aarch64__`	`1`
`__arm__`	`1`
`__PPC__`	`1`
`__x86_64__`	`1`

OpenArbor version 12.6.0 and Earlier

For OA versions prior to 13.0.0 (e.g. 12.6.0 and earlier), step 1 in the #Existing OA Project process must be replaced with the following:

File → New → Project → C/C++ → Makefile Project with Existing Code
1. Project Name : <proj>-test
2. Existing Code Location: ~/scm/Deos/products/<proj>/branches/mainline/tests
3. Toolchain for Indexer Settings: <none>
4. Select "Finish"

Copy Component files to DESK

If you are running tests against the component in your desk (ie. a released or un-released version), then skip this section.

If you are testing a component that was built locally, you will need to copy the modified/compiled component files into the desk. Navigate to the top level directory of component (e.g. mainline), and perform ONE of the following commands:

From Windows:

cp -rva output/desk /

unzip -o *.zip -d /output/desk

From WSL/Docker:

sudo cp -rva output/desk /

The locally compiled/produced component files will then overwrite the files in the DESK.

Building Tests

Preconditions

The following instructions assume the following:

The components listed in the test readme have been installed
The target BSP has been installed

From Command Line

Test execution can be initiated from linux/BASH windows, or from a Terminal window within OpenArbor (see #Launch_Terminal_Window).

The instructions for building tests are located in the corresponding test readme.txt file or here: Building_The_Tests

For most tests, navigate to the appropriate ./tests folder, and use the commands specified in the corresponding test readme file. Generally, the regress build command uses the following format:
./common/test-utils/regress <component_name> so <target_name> build

Examples are provided below:
./common/test-utils/regress -q ansi so qemu-arm build
./common/test-utils/regress -q deos653p1 so qemu-ppc build tp0090

In OpenArbor

If the instructions above for #Component_Test_Settings have been followed, then you can build the test procedures using the following OpenArbor command:
Project:Build Project

Running Tests

Preconditions

The following instructions assume the following:

The components listed in the test readme have been installed
The target BSP has been installed

From Command Line

Test execution can be initiated from linux/BASH windows, or from a Terminal window within OpenArbor.

The instructions for running tests are located in the corresponding test readme.txt file or here: Running_The_Tests

The general steps to execute tests from a command line are as follows:

Start target platform
Set the desk IP address
Execute the test (via regress script)

Start Target Platform

If the target is an actual hardware platform, then follow the steps as given on the X-9 page for locking and starting the needed hardware target board.

If the target is a qemu platform, then launch the qemu via the Launch Emulator icon in the Target Manager window of OpenArbor.

Set DESK IP Address

From the Linux/BASH or Terminal Window, run the following command to set up the DESK IP address of the target board:
export DESK_IP_ADDR_xxxxx=WWW.XXX.YYY.ZZZ

Examples are as follows:

export DESK_IP=192.168.19.17
export DESK_IP_ADDR_qemu_arm=192.168.19.17
export DESK_IP_ADDR_qemu_ppc=192.168.19.33
export DESK_IP_ADDR_zcu102=10.0.1.65

Execute Test(s)

For most tests, navigate to the appropriate ./tests folder, and use the commands specified in the corresponding test readme file. Generally, the regress build command uses the following format:
./common/test-utils/regress <component_name> so <target_name> run <variant>

Examples are provided below:
./common/test-utils/regress -q ansi so qemu-arm run release instrumented instrumented_optimized
./common/test-utils/regress -q deos653p1 so qemu-ppc run release tp0090

In OpenArbor

If you want to run your test using OpenArbor, the following steps are needed:

Project properties → Run/Debug Settings → New... → C/C++ Application
1. Main tab
  1. C/C++ Application:
    ${env_var:DESKHOME}/../bin/bash [for Linux environments]
    ${env_var:DESKHOME}/../bin/bash.exe [for windows environments]
2. Arguments tab
  1. Program arguments: common/test-utils/regress <proj> so qemu-arm local run release
3. Environment tab
  1. Add... (as needed)
    
    Name Value
    
    DESK_IP_ADDR_qemu_arm 192.168.19.17
    
    DESK_IP_ADDR_qemu_ppc 192.168.19.33
    
    DESK_IP_ADDR_qemu_x86 192.168.19.49
  2. Select "Apply"
  3. Select "OK"
4. Select "Apply and Close"

From the Target Manager window in OpenArbor, launch the appropriate emulator (qemu-arm for example).

To build the test files, select Project: Build Project

To build and run test files:
1. Run: Run Configuration ...
2. Select the "Arguments" tab and confirm the command line is correct
3. NOTE: if you want to run all tests for the component then you do not need to specify a test name. If you want to run only one test then you must add the test name to the end of the command line (such as tp0001). If you want to run multiple tests, then list each test with a space delimiter (tp0001 tp0003 tp0014).
4. Select "Run"

Name	Value
`DESK_IP_ADDR_qemu_arm`	`192.168.19.17`
`DESK_IP_ADDR_qemu_ppc`	`192.168.19.33`
`DESK_IP_ADDR_qemu_x86`	`192.168.19.49`

Debugging in OA

This section should be used in addition to the debugging information provided in the OA User Guide.

Launch Debugger

To run/load the debugger in OpenArbor, the following steps are needed:

Run the test using the steps explained in the Running Tests section above
From the target manager window, select the Status Monitor associated with the emulator in use (qemu-arm for example)
1. Right click the Status Monitor and select Enable
2. Expand the Status Monitor (in the same window) to view the list of processes running
3. Select the test procedure process (tp0001.exe for example)
4. Right click and select Debug with gdb
5. A debug window will show up in Open Arbor. From this window, do the following:
  1. Select "Search the DESK"
  2. Select "Search" and browse to the test directory for the component you are debugging
  3. Select "OK" from browse window
  4. Select "OK" from the debug window
6. OpenArbor will then switch to the debug version of the GUI

Activate Breakpoints

If you need to add breakpoints to the software while debugging in OA, you must first activate the breakpoint support using the following steps:

Modify the specific pd.xml (or 653 config file) as follows:
1. Change breakAtStartup to be "yes"
2. Change InDebugSet to "yes"
Rebuild the associated test procedure
From the target manager, select the target you are using, the select Edit Attributes icon:
1. Select Edit Attributes
2. Check "Honor debug services"
3. Check "Force cold start"

Add Breakpoints

You can add breakpoints as follows from the OA editor:

Navigate to the code file and specific line in question
Select the line
Right click in the line number column (or the tiny gutter column) and select "Toggle breakpoint"

NOTE: Once the debugger is running, you can confirm/remove your breakpoints in the "Breakpoints" tab in the right-most debugging pane in OA.

Alternate Approach to Adding Breakpoints in Software

Instead of using the built in breakpoint capabilities of OA, you can modify the software (generally the test procedure) to hard code a breakpoint macro.

Add the following line of code into the software that you are debugging
1. BRKPT;
Build the software (test procedure)
NOTE:The above approach will cause the software to halt at the BRKPT location. At this point, you can add normal breakpoints. To start the software running again, follow these steps:
1. Use the debugger and select "Move To Line" immediately past the BRKPT location in the software
2. Select the "resume" icon

Using Timestamps to Debug

When output (tout) calls are not reasonable, then an alternative approach to debugging is to use the logSystemEvent() calls to log unique data values into the event log.

Add logSystemEvent(0x101), 0x102, etc to the software
Add the following to the test procedure once the logging is completed

waitUntilNextPeriod();
waitUntilNextPeriod();
disableSystemEventLog();
while(1) waitUntilNextPeriod();

Rebuild the software
Run using the “local” option with regress if the logSystemEvent calls were added to the component softwae
Once the test is complete, then do the following:
- Select the platform from the Target Manager window in OA
- Click the Gather Timemap icon in the Target Manager
- Click the Save icon to store the file in text format
- Using OA, navigate to the qemu-arm/output folder (or whichever target platform you are using) and find the timemap outfile file (eg. qemu-arm.timemap). Right click the file and select Open With: Text Editor
- Search for “User” and you can see how the system event data is logged as an aid to debugging various issues (timing, internal variable values, etc)

OpenArbor Examples

Most components have OA Example projects where specific component functionality is demonstrated. Any example that has been installed in the desk can be loaded and run in OpenArbor. This section provides the general steps to load and run examples.

Please refer to the specific User Guide associated with the component's examples for more information.

To run an OpenArbor example, you will need to import the example, import the platform, and then run the actual example. The steps are explained in the following subsections.

Import Example

From within OpenArbor, follow these steps:

New: DDC-I Deos Example Projects
Select the examples to import
Select the Target (pull down field)
Select Finish

Following the above steps will create one or more project folders in the DDC-I Project Window explorer.

Import Platform

To run an example, you also need to import the desired target platform. Within OpenArbor, follow these steps:

New: DDC-I Deos Platform Project
Select the platform (such as qemu-arm)
Select Finish

Run an Example

Launch the desired platform

From the Target Manager, select the Launch Emulator icon (it is the green "play" button)

Add a Dependency from the Target Platform to the Example

Option 1: From the DDC-I Project Window, drag the example project folder onto the platform folder
Option 2: Open the platform folder, open the "Deos Component" folder, and right-click the "Dependencies" folder
- Add Dependency
- From the "Dependency" pull down field, select the example
- Select OK

Confirm the Dependency

From the DDC-I Project Window, open the platform folder
Open the Deos Component folder
Open the Dependencies folder
Confirm that the example is listed (along with other standard/default dependencies)

Run The Example

From the Target Manager window, select the platform
Select the "Update Target Load" icon at the top of the Target Manager window

If all went as planned, the example will run on the selected platform.

Disconnect the Example

When you have finished with the example, you will need to remove the dependency from the target platform to the example.
This is especially important if you want to run a different example.

From the DDC-I Project Window, open the platform folder
Open the "Deos Component" folder
Open the "Dependencies" folder
Select the example dependency
Right click and select "Remove Dependency"

Miscellaneous

Suggested OpenArbor Preferences

The following preferences are suggested when using OpenArbor as a text editor:

Turn on line numbers: The default OpenArbor behavior is no line numbers.
Windows → Preferences → General → Editors → Text Editors
Select "Show line numbers"
Disable tabs: The default OpenArbor behavior is use tabs instead of spaces.
Windows → Preferences → General → Editors → Text Editors
Select "Insert spaces for tabs"

Syntax Warnings in OA

After creating your OA project, OA will often display a large number of syntax warnings (indicated by yellow bug on offending line). To resolve this issue, use the following command:

Right-click the project in the Project Window
Index: Freshen All Files

Launch Terminal Window from OpenArbor

A terminal window can be launched from OA. This will provide the user with a "Terminal" tab that provides the user with the ability to enter Linux/BASH command lines.
To launch a terminal window, use the following instructions:

select the terminal icon in the icon bar, or use Shift-Control-Alt-t
Choose terminal: Local Terminal
Encoding: UTF-8
Select OK

Using OpenArbor as an HTML editor

Editting of an HTML, HTM, or XML file can be done within the OpenArbor editor
For more advanced HTML editing, you can install the Eclipse Web Developer Tools (Help: Eclipse Marketplace..). This is a text based editor, but the HTML is color coded, much like Notepad++. To edit an HTML file, select Open With....HTML Editor. While editing you can right click in the file and select Open With....Web Browser, which will open another, read only, tab displaying the page.

Old QEMU IP Addresses

Older versions of qemu will use the following addresses:

Name	Value
`DESK_IP_ADDR_qemu_arm`	`192.168.19.103`
`DESK_IP_ADDR_qemu_ppc`	`192.168.19.102`
`DESK_IP_ADDR_qemu_x86`	`192.168.19.100`

Timing Problems on Qemu-arm and Qemu-aarch64 (PCR 15585)

Certain tests that require high precision timing will fail on qemu-arm and qemu-aarch (see PCR 15585). A work-around for this issue is to turn the sleep mode to ON for these two platforms. Use the following instructions to enable sleep mode on these two qemu platforms until PCR 15585 has been resolved:

From Open Arbor, select the “qemu-arm” project (in the DDC-I Project Window), right click, and select “properties”.
Select the “Deos” tab and then select the “Boot Image” tab
Enter the following bash command into the “Command:” box, and select “Apply and Close”: startqemu --qemu-args='-icount align=off,shift=0,sleep=off'

Deos Maintainer Build In OpenArbor

Summary

Additional OpenArbor resources

Create a New Project

Preconditions

Existing OA Project

New OA Project

OpenArbor version 12.6.0 and Earlier

Copy Component files to DESK

Building Tests

Preconditions

From Command Line

In OpenArbor

Running Tests

Preconditions

From Command Line

Start Target Platform

Set DESK IP Address

Execute Test(s)

In OpenArbor

Debugging in OA

Launch Debugger

Activate Breakpoints

Add Breakpoints

Alternate Approach to Adding Breakpoints in Software

Using Timestamps to Debug

OpenArbor Examples

Import Example

Import Platform

Run an Example

Launch the desired platform

Add a Dependency from the Target Platform to the Example

Confirm the Dependency

Run The Example

Disconnect the Example

Miscellaneous

Suggested OpenArbor Preferences

Syntax Warnings in OA

Launch Terminal Window from OpenArbor

Using OpenArbor as an HTML editor

Old QEMU IP Addresses

Timing Problems on Qemu-arm and Qemu-aarch64 (PCR 15585)

Navigation menu

Search