RTEMS-Goddard-Microblaze-SoW2.pdf

Statement of Work for

RTEMS Microblaze Support

5 January 2020

Prepared by

OAR Corporation 990 Explorer Blvd., Huntsville, AL 35806

Voice: +1 256-722-9985 Fax: +1 256-327-0702

DRAFT

11.0 BACKGROUND / OBJECTIVES

RTEMS is a real-time operating system designed to provide deterministic performance across a variety of hardware platforms. It includes support for various filesystems, networking, and symmetric multiprocessing (SMP). RTEMS has support for a variety of 32-bit and 64-bit architectures but does not currently support the Xilinx Microblaze.

The primary goal of this task is to develop a port to the Microblaze architecture, an RTEMS Board Support Package (BSP), and the associated supporting software for the Xilinx Microblaze System on Chip (SoC). Upon completion, the software will be submitted to the upstream open source project for incorporation.

This Statement of Work (SoW) specifies the software engineering services to be provided by the OAR Corporation team.

2.0 TECHNICAL REQUIREMENTS

This section is organized based on development of a Microblaze architectural port and basic BSP for a simulator followed by a series of optional follow-on tasks.

2.1 RTEMS Xilinx Microblaze Port and Simulator Basic BSP Development

OAR Corporation shall develop RTEMS support for the Xilinx Microblaze SoC. The RTEMS Xilinx Microblaze SoC support shall be developed to the following requirements:

Shall utilize the GNU Cross Development Tool Suite to support the 32-bit RTEMS Microblaze (e.g. microblaze-rtems target). The Tool Suite consists of the GNU Binary Utilities (binutils), GNU Compiler Collection (GCC), GNU Debugger (gdb), and the Newlib Standard C Library.

Shall modify the RTEMS Source Builder to include build recipes for the microblaze-rtems Tool Suite.

Shall include an architectural port of RTEMS to the microblaze-rtems target including big- and little-endian support. This includes addition of a Microblaze specific section to the RTEMS CPU Architecture Supplement.

Shall include a basic RTEMS Board Support Package (BSP) for the QEMU target simulator platform for the Microblaze using the KCU105 model. This BSP provides support initialization, clock tick device driver, console, and interrupt processing. This includes addition of a section to the RTEMS User Manual to cover basic setup and use of this BSP.

Support shall be added to the RTEMS Tester for the QEMU target simulator BSP to automate regression testing. This enables testing of all core RTEMS functionality including the POSIX and Classic APIs.

Shall use the RTEMS Tester to execute and debug all applicable tests from the RTEMS Test Suite on the QEMU simulator BSP.

All source code that is not specific to the objective custom target hardware shall be submitted for inclusion to the rtems.org open source project.

Deliverables:

RTEMS source code with Microblaze 32-bit support, BSP for the QEMU simulator.

RTEMS Tester with additions to support testing on the developed BSPs.

Updated RTEMS documentation.

22.2 Network Support Development

OAR Corporation shall develop RTEMS network support for the Xilinx Microblaze SoC to the following requirements:

Support shall be added to the RTEMS libbsd TCP/IP stack for the microblaze-rtems target.

Shall provide a network driver for the Microblaze QEMU simulator target. This includes appropriate documentation for use of this network driver.

All source code that is not specific to the objective custom target hardware shall be submitted for inclusion to the rtems.org open source project.

Deliverables:

RTEMS libbsd TCP/IP stack source code with Microblaze 32-bit support.

Updated RTEMS documentation.

2.3 Support NASA Bring Up on Custom SoC

As the initial BSP was developed for the QEMU simulator and NASA’s goal is to have RTEMS on a custom Microblaze SoC, OAR Corporation shall:

Support NASA in adapting the QEMU simulator BSP to create a variant that works on the objective custom NASA Microblaze SoC.

Support upstreaming any appropriate software to the rtems.org open source project.

Deliverables:

None

22.4 Microblaze Multi-Threaded GDB Server Support Development (Optional)

OAR Corporation shall develop RTEMS GDB (libdebugger) server support for the Xilinx Microblaze SoC to the following requirements:

Add support to the RTEMS thread aware GDB Server for Microblaze.

Test the GDB Server.

Document usage and testing of the GDB Server.

All source code that is not specific to the objective custom target hardware shall be submitted for inclusion to the rtems.org open source project.

Deliverables:

RTEMS GDB Server source code and supporting tests.

Documentation related to GDB Server.

NOTES:

At this point, it is unknown whether this can be tested on QEMU or requires the custom NASA Microblaze SoC. Debugging may require special registers not available on QEMU.

This SOW assumes that this will have to be developed and debugged on the custom NASA Microblaze SoC as processor debug registers are often not supported by QEMU.

2.5 Flash Device Driver Support Development (Optional)

OAR Corporation shall develop RTEMS flash device driver for the Xilinx Microblaze SoC to the following requirements:

Device driver support shall be added to the NASA Microblaze SoC BSP for the ONFI compatible flash.

Shall ensure the Flash can be used via filesystem operations.

Shall test the Flash device driver.

Shall document usage and testing of the Flash device driver.

All source code that is not specific to the objective custom target hardware shall be submitted for inclusion to the rtems.org open source project.

Deliverables:

RTEMS flash device driver source code and supporting tests.

Documentation related to flash device driver.

22.6 GPIO Device Driver Support Development (Optional)

OAR Corporation shall develop RTEMS GPIO device driver for the Xilinx Microblaze SoC to the following requirements:

GPIO device driver support shall be added to the NASA Microblaze SoC BSP.

Shall test the GPIO device driver.

Shall document usage and testing of the GPIO device driver.

All source code that is not specific to the objective custom target hardware shall be submitted for inclusion to the rtems.org open source project.

Deliverables:

RTEMS GPIO driver source code and supporting tests.

Documentation related to GPIO device driver.

3.0 TASK MANAGEMENT / REPORTING REQUIREMENTS

The following reports will be prepared by OAR Corporation and submitted to the customer.

Monthly Status Reports – The subcontractor shall prepare a Monthly Status Report due on the 5th day of each month, which will include a Technical Status Report and a Business Status Report.

Final Technical Report – At the completion of the subcontract, the subcontractor shall submit a Final Technical Report, which will provide a comprehensive, cumulative, and substantive summary of the progress and significant accomplishments achieved during the total period of the effort. Report shall be submitted 15 calendar days following the end of the period of performance.

Contractor format is acceptable for the above reports.

3.1 Points of Contact

Please fill in the table below for the purpose of sharing technical reports:

NASA POC: OAR POC:

Jeff Mayes, RTEMS Project Lead

Jeff.Mayes@OARcorp.com

44.0 SECURITY REQUIREMENTS

The security classification level for this effort is UNCLASSIFIED. The subcontractor shall not have access to classified data/information for this effort.

5.0 TRAVEL AND OTHER DIRECT COSTS (ODCs)

5.1 Travel

No travel is anticipated for this effort.

5.2 ODCs

Most of this development effort will be done on the QEMU simulator. Except for the following, there should not be any special equipment or target boards required.

NASA will provide suitable target hardware and debug peripherals for OAR to utilize during the POP. The board will be returned to NASA upon project completion.

6.0 PERSONNEL QUALIFICATIONS

The subcontractor shall possess the necessary training, qualifications, and experience to accomplish all tasks identified in this SoW.

7.0 PERIOD AND PLACE OF PERFORMANCE

7.1 Period of Performance (PoP)

The period of performance shall be no longer than 12 months after the contract award date. Since portions of this effort are optional, the exact PoP dates cannot be determined now. Once those dates are defined in detail, they will be documented here.

7.2 Place of Performance

The primary place of performance will be the subcontractor’s facility.