Surcouf Program

From DDCIDeos
Jump to navigationJump to search

Overview

MDA in Montreal, QC, Canada.
Customer's Product: Communications Subsystem for the Dream Chaser
Hardware: Aitech PowerQUICC-III MPC8548E
Expected cert: Janurary 2020
Current SoW: SoW
Baseline: Greys
Components: Verified BSP
Technical Contact: Francois Arsenault
Management Contact: Guillaume Lemieux; phone: (514)654-4432.
SQA Contact: TBD
Deos Management Contact: Bill Cronk
Deos Technical Contact: TBD

Charge Codes: Deos Surcouf - 2120-207-600

Current Release:


Milestones

Deos Surcouf Milestones
Program Milestones Type Stable Date SoW Date Cur. Date Status
Surcouf D1 - RTOS & IDE for PowerPC Development Release 2017-12-29 2017-12-29 2017-12-29 Done
Surcouf D2 - RTOS for BBM (COTS card) Release 2018-03-07 2018-03-14 2018-03-14 Done
Surcouf D3 - RTOS for BBP EDU Release 2018-12-20 2018-12-27 2019-01-22 Done
Surcouf D3b - RTOS for BBP EDU Release 2019-02-19 2019-02-19 2019-02-19 Done
Surcouf D3c - RTOS for BBP EDU Release 2019-02-22 2019-02-28 2019-02-28 Done
Surcouf D3e - PCI bus init - partial implementation Release 2019-04-03 2019-04-05 2019-05-02 Done
Surcouf D4 - RTOS for BBP QM - full functionality Release 2019-07-25 2019-08-07 2019-08-14 Done
Surcouf D5 - Updates from testing Release 2019-10-25 2019-11-05 2019-11-11 Done
Surcouf D6 - Verified Components Release 2020-05-26 N/A 2020-05-28 Done
Surcouf Cert Artifact Delivery Documents N/A N/A 2020-05-28 Done

Projects

Reference, Production and Verified versions:


Surcouf Board Unavailability Log

Since the board is remote in Canada, we track moments on which the board is not available for development/debugging, along with the reason. The main purpose is to show how no access to the target impacts the work that needs to be performed. See the log in Surcouf Board Unavailability Log.


Code Name

The code name was chosen for yelp's highest rated resturant in the area - le Surcouf.

Development Notes:

  • Implement CRC check on psio data in boot
  • Fix capture of hyperstart data in PSIO. Golden was failing.
  • Evaluate DBCR0
  • Document implementation, requirements and test for RAM tests.
  • Pattern test add test point to inject error before setDRAMPattern
  • Evaluate address bus test
  • Also, discuss error detection through interrupt vs MC. Boot to set registers described in HID1 section on RFXE
  • Gold will attempt boot if signature fails, crc fails, pdt crc fails, pdt null pointer(this will not boot ever)
  • Check real machine check fault during RAM tests (results in target hang checkstop) Inserted MBE during RAM tests
  • Evaluate PMGC0
  • Log machine check registers in FPGA on machine check.
  • Implement correct reporting of bus fault values for interrupt with RFXE=0
  • Add memory map to requirements
  • Update UG to describe fault fields in FPGA scratch and PSIO registers. Already in UG 3.1.12. Target Reset and Error Reporting
  • Pointer to checkstop ECC information
  • Evaluate Device setup in PAL
  • Update UG to reflect device library API
  • Implement and document device initialization and use in PAL
  • Set RFXE to 1 for RAM test to cause checkstop (maybe)
  • Re-order RAM tests. Pattern test first. Is ECC needed for testing? If so, increases boot time from ~15 secs to ~120 secs.
  • Requirement and Code Updates
    • Image retry on failures
    • Follow flowchart in Q+A
    • Fault log and reset on Gold error as well
    • New memory map may require document updates describing Gold and Writeable images.
  • Watchdog back to 2 mins
  • Make sure all interrupts work and users have control over IVPR P and S bits for external interrupts. Document in UG how these can be set for a user external interrupt.
  • Check use of case statment in PAL for network interrupt aggregation is appropriate
  • Check for signature in hypstart image, don't do CRC if signature is not valid.
  • Use FPGA internal WD 1 tick = 48ns for development. Check that certified versions of files (ANSI in particular) are used in the build.
  • Evaluate L1CSR1 (ICPE bit won't set, assembly code writes correct value to correct SPR)
  • Evaluate instrumented builds with regards to full RAM test L2 Cache SRAM configuration Use 64KB
  • Evaluate entire test environment
  • Evaluate PEX error enable register PEX_ERR_DR (SP0 board has no PCIe interface)

Remote Access Test with Nicolas Cuvillier 10/31/2018

  • Positives
    • Basic connection was good.
    • Connection to Lauterbach Trace32 software worked
    • File transfers possible through TeamViewer software
  • Negatives
    • TeamViewer must be purchased for commercial use. The free download version is full-featured but limited to a 7 day trial. Who is going to pay for this?
    • No means to control target and emulator power
    • OA is installed, but the VM does not have access to MDA license server. A license has to be added to this machine. Don't just want to do our generic development license we use at DDC-I, since developers at MDA have access to the PC and VM
    • No serial connection set up.
    • TeamViewer has to be running on the remote PC. May require human interaction if the PC is used for other MDA purposes with TeamViewer off.
    • The ultimate goal would be unlimited access to the remote PC and target without any interaction from MDA personnel. Indications are this will not be the case. We need to ask directly.
    • Our software development environment is not on the remote PC. This will cause a lengthened development and test cycle. Can we get our environment on the remote machine without giving away any DDC-I proprietary information?

Analysis of System Requirements

  • 3.3.2.1 SBC FPGA Scratch Registers
    • A scratch register is a register that survive a Warm boot and is reset to 0 on a Cold boot (power on reset). The SBC supports up to 40 scratch registers and (TBC)10 scratch registers are availableto the DBS. Refer to RD 4 for more information.
      • How many scratch registers are available for use by the DDC-I BSP components?
  • 4.1.1 DBS Capability
    • Table 4-1 NOR Flash Memory Mapping
      • All Start Addresses marked as TBD
        • What are the expected NOR Flash addresses?
    • (TBC) If the CPU fails the initialization process, the SBC FPGA bootstrap watchdog will reset the CPU. TBC explanations: Because the FTFC is supervising the BBP system, it may be decided to remove the bootstrap watchdog and let the FTFC manage the BBP reset from a system point of view.
      • What is the expected watchdog behavior during boot?'
    • 4.1.1.1 Boot Transition Time from Power-Off to Power-On Self-Tests
      • Requirement ID: DBS-100 Parent Requirement ID: CRG_BBP-114
        The DBS shall start “Power-On Self-Tests” (POST) within (TBC)10 msec after start of execution.
        Note: Start of execution can be initiated after power application to the BBP SBC or CPU reset.
        • Performance requirement that cannot be measured until full boot requirements implementation on real hardware.
    • 4.1.1.3 SBC FPGA Bootstrap Watchdog Initialization
      • Requirement ID: DBS-113 Parent Requirement ID: Derived
        The DBS shall be program the SNC FPGA bootstrap watchdog to 2 minutes (TBC).
        • What is the expected watchdog behavior during boot?'
    • 4.1.1.4 Boot Initialization Sequence Timing
      • Requirement ID: DBS-107 Parent Requirement ID: CRG_BBP-500
        The DBS shall perform the following boot sequence within 105 seconds (TBR) after power is applied to the Base-band Processor (BBP):
        • Performance requirement that cannot be measured until full boot requirements implementation on real hardware.
    • 4.1.1.8 Machine Check Configuration
      • Requirement ID: DBS-103 Parent Requirement ID: Derived
        The DBS shall perform the following in the case of a processor Machine Check error:
        Log the error TBD code in the TBD SBC.FPGA scratch register
        Reset the processor
        Details of the SBC.FPGA scratch registry mapping will be provided by MDA.
        The RTOS will use the same Machine Check error handler as the DBS.
        • Error code and scratch register layout can be determined by DDC-I when FPGA scratch register availability question is resolved.
    • RAM Tests
      • 4.1.1.9 POST Data RAM Tests
        4.1.1.10 POST Address RAM Tests
        • Do tests include checks for ECC errors? If so, boot time increases by a factor of 10 (~12secs to ~120secs as measured on reference board). Performance requirement that cannot be measured until full boot requirements implementation on real hardware. Error code and scratch register layout can be determined by DDC-I when FPGA scratch register availability question is resolved.
    • 4.1.1.12 Flight Software Image Selection and Loading Sequence
      • Checks for image validity in flash and multiple load attempts will increase measured boot time. Performance requirement that cannot be measured until full boot requirements implementation on real hardware. Error code and scratch register layout can be determined by DDC-I when FPGA scratch register availability question is resolved.
    • 4.1.1.19 Boot Report Structure
      • Table 4-3 DBS Boot Report Section Definition
        • TBD error codes and scratch register layout can be determined by DDC-I when FPGA scratch register availability question is resolved. Important to remember that none of this information is persistent if power cycle is performed.
    • 4.1.1.21 DBS Memory Footprint
      • Requirement ID: DBS-141 Parent Requirement ID: Derived
        The DBS image size shall consume no more than 1.5% of the 8 megabytes SBC NOR Flash.
        • Performance requirement that cannot be measured until full boot requirements implementation on real hardware.
    • 4.1.2.3 Interrupt and Scheduling Latency
      • Table 4-4 RTOS Latency Time Performance
        • TBCs in table represent performance requirement that cannot be measured until full system requirements implementation on real hardware.
  • Ethernet Configuration and Topology
    • TBCs in table represent performance requirement that cannot be measured until full system requirements implementation on real hardware.
  • Platform Device Configuration
    • Various devices not related to correct Deos operation, but to operational system requirements, need to be initialized. The proposal is to provide calls to a user-supplied library from the PAL start-up routines. This provides a single-threaded environment to avoid contention for resources during start-up. Multiple devices on the PCIe bus attempting initialization during normal run-time is an example of the possible contention scenario. A user-defined library provides the flexibility to set up any system devices to any state during the start-up sequence. The DDC-I expectation is that at least one system device will be available on the real hardware. We will define the software interfaces for the library and provide an example for initialization of the one device. MDA will take control of the library to develop and test required devices to meet operational system requirements. DDC-I responsibility is to ensure the defined software interfaces to the user-supplied library are called appropriately.

Additional Information

As of 10/19/2018, the project is in a hold state awaiting three items:

  • Requirements agreement between DDC-I and MDA
  • Updated hardware - Last status meeting indicated third week in November
  • MDA expects remote BSP development on new MDA hardware when it arrives. Limited questions but no actions from MDA to make this possible.

Unreleased boot, config, and Pal components are available through Cygwin and reflect the currents set of requirement under review at MDA. General review discussion in the weekly status meeting that even though there are TBDs and TBCs in their system level requirements, we are not at liberty in most cases to suggest an optimal approach. Their response has been, we agreed with our customer on a feature or implementation so we need you to follow our spec with regards to defined platform specific features. Primary example is the hyperstart selection flowchart specified in Section 4.1.1.12 Flight Software Image Selection and Loading Sequence System Requirements

The development advice is to be alert for platform specific requirements in the System Requirements above. Implement as described, regardless of any performance requirement they may have set for the feature. MDA has been inconsistent with their priority between boot time and platform specific feature set. Implement the platform specific feature set and time can be measured on the new hardware. As mentioned, MDA has most likely agreed to the implementation details and does not want to go back to their customer with proposed changes.

Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=Surcouf_Program&oldid=72330"